Nabble - MicroControllers - Ethernut

Re: Preferred way to send patches

2009-11-08T03:30:30Z

Harald Kipp wrote:
> the trunk. Except the AT91 EMAC enhancements / fixes from Thiago.
> Ethernut 3 hangs sometimes when loading the flash animation included in

This was nonsense. Ethernut 3 doesn't use the AT91 EMAC driver. Sorry
for any confusion.

Harald

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

Re: Preferred way to send patches

2009-11-06T10:54:14Z

Ole Reinhardt wrote:
> For me the patch sounds reasonable. But I won't be able to check it in
> before end of next week as I'm now going on holidays...

Thanks, Ole for offering your help. Today I applied all open patches to
the trunk. Except the AT91 EMAC enhancements / fixes from Thiago.
Ethernut 3 hangs sometimes when loading the flash animation included in
app/httpd. I'll have to check this in more detail.

Harald

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

Re: Preferred way to send patches

2009-11-06T09:34:28Z

Shouldn't we also apply that to the other platforms?
Could perhaps be in nutconf as well...

On Fri, Nov 6, 2009 at 3:11 PM, Ole Reinhardt
<ole.reinhardt@...> wrote:

> Hi Uwe,
>
>> http://lists.egnite.de/pipermail/en-nut-discussion/2009-February/010399.html
>
> For me the patch sounds reasonable. But I won't be able to check it in
> before end of next week as I'm now going on holidays...
>
> 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
>

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

Re: Preferred way to send patches

2009-11-06T09:11:49Z

Hi Uwe,

> http://lists.egnite.de/pipermail/en-nut-discussion/2009-February/010399.html

For me the patch sounds reasonable. But I won't be able to check it in
before end of next week as I'm now going on holidays...

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: ARP and UDP

2009-11-06T06:49:48Z

Hi Paolo,

Following my previous post about this question, after a lot of
> packet sniffing with ettercap, wireshark and tcpdump.
> i can definitively say that if you throw out an UDP packet
> very early (seems about before 500 ms) after opening the socket
> it gets lost into the TCP guts of NutOs :( ...
>

If you can send one of the network dumps to this list maybe someone
will have an idea of what is happening. It would be best if the time stamps
were either absolute (time of day) or relative for only the packets of
interest
("seconds since previously displayed packet" in wireshark).

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

ARP and UDP

2009-11-06T04:27:51Z

Hi all,

Following my previous post about this question, after a lot of
packet sniffing with ettercap, wireshark and tcpdump.
i can definitively say that if you throw out an UDP packet
very early (seems about before 500 ms) after opening the socket
it gets lost into the TCP guts of NutOs :( ...

In his reply Ole pointed out that if was possible that
ethernut fired the packet too early for the UDP server
to complete his ARP table, but it seems to me that the
problem is on the ethernut side, :( things go like this:

ARP request starts from ethernut
the server replies with its IP

then two cases:
if you send an UDP packet within 500 ms, just
nothing comes out from the etherenet

if you send an UDP packet after 500 ms all is fine

probably ethernut has not built its ARP table
and just silently discards the packet, second one
goes like a breeze !

NutSleep(500); before sending out the first packet
resolves the issue

maybe TCP seems not affected by this behaviour due to
protocol retries that mask the problem

Sorry to appear pedantic about this question,
but i'm developing an application that sends out
just one packet ;-) ...

Ciao.
Paolo

--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Legal.email.it: il servizio di Posta elettronica certificata con SMS di notifica per aziende e liberi professionisti. Secondo la normativa vigente l'ultimo giorno per mettersi in regola è il 29 novembre 2009.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8979&d=6-11
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Dual rs232<->Ethernet

2009-11-06T03:26:01Z

Hi all!
After some tries I'm get fully workable code. You can see that here:
http://pastebin.mozilla-russia.org/102504

But I still have rare freezes, and need to manually reset my device.
Have a chance to resolve this?

2009/10/27 asdus <asdusik@...>:
> Hi all.
> For my home automation i need to use 2 rs232<->ethernet converters
> I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
> TCP Server and Serial Port Monitor examples.
> Using that i need to do this in dedicated threads, because i'm use
> other ethernut's digital pins to get home events. All my tries fails,
> i have lags using my remote rs232's.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Preferred way to send patches

2009-11-06T02:07:30Z

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt@...> writes:

Ole> Hi Uwe,
>> what is the preferred way to send patches? This list, the sourceforge
>> tracker or another media.

Ole> Te sourceforge tracker is a good place to place patches. If you
Ole> send a message to the list too your path will be noticed earlier.

Thanks.

>> Anyway, I enter a patch to Allow to pass options to ROM/HEX/BIN
>> Generation on this list (some time ago) and on the tracker, with no
>> reaction so long.

Ole> Sorry if your message did not get any notice...

Ole> I searched the archive but did not find any patch concerning the
Ole> binary / hex generation? Do you have a link (to the archive) or
Ole> could you tell me the date?

It has been some time:

http://lists.egnite.de/pipermail/en-nut-discussion/2009-February/010399.html

Bye
--
Uwe Bonnes bon@...

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Preferred way to send patches

2009-11-06T01:21:25Z

Hi Uwe,

> what is the preferred way to send patches? This list, the sourceforge
> tracker or another media.

Te sourceforge tracker is a good place to place patches. If you send a
message to the list too your path will be noticed earlier.

> Anyway, I enter a patch to
> Allow to pass options to ROM/HEX/BIN Generation
> on this list (some time ago) and on the tracker, with no reaction so long.

Sorry if your message did not get any notice...

I searched the archive but did not find any patch concerning the
binary / hex generation? Do you have a link (to the archive) or could
you tell me the date?

I will review it asap, but from tomorrow on I'll be on holidays for a
week.

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

Preferred way to send patches

2009-11-05T07:11:29Z

Hello,

what is the preferred way to send patches? This list, the sourceforge
tracker or another media.

Anyway, I enter a patch to
Allow to pass options to ROM/HEX/BIN Generation
on this list (some time ago) and on the tracker, with no reaction so long.

Bye
--
Uwe Bonnes bon@...

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Different automatically generated build trees in Linux and Windows for NutOS 4.8 (was Re: "US_PIOA_PINS_A" redefined)

2009-11-05T04:40:35Z

OK, going forward.

The problem seems to the version of nutconf that I was using. It seems
that somehow version 1.4.3 was generating the build tree wrongly for me.
I have tried now with versions 2.0.5 and 2.0.9, and they both work.

I am still surprised. Has there been any significant changes between
versions so that this can happen? Does this mean that something has
changed in the .nut and .conf files so that they require nutconf version 2?

Regards
José

José Vallet wrote:

> Hello all.
>
> I am still struggling to compile a fresh ethernut-4.8.* in my linux.
>
> The previous short thread can be found at
> http://groups.google.com/group/osdeve_mirror_rtos_en-nut-discussion/browse_frm/thread/20c243fe22b49b5b/f36336950173ab7e?hl=en&lnk=gst&q=%22US_PIOA_PINS_A%22+redefined#f36336950173ab7e
>
> This time I tried 4.8.5, with the same result:
> -------
> /home/jose/ethernut2/ethernut-4.8.5/arch/arm/dev/usart0at91.c:229:1:
> error: "US_PIOA_PINS_A" redefined
> /home/jose/ethernut2/ethernut-4.8.5/arch/arm/dev/usart0at91.c:215:1:
> error: this is the location of the previous definition
> -------
>
> As Marcus Jansson kindly pointed, it seems to be due to having multiple
> MCUs defined. Let me recall that I have not modified the sources, I am
> using a fresh downloaded ethernut-4.8.5 package.
>
> Trying to dig into this I noticed that the automatically generated
> nut-bld/include/cfg/arch.h has, among PLATFORM and ARM_GCC, the
> following MCUs defined: MCU_AT91R40008, MCU_AT91, MCU_AT91SAM7S,
> MCU_AT91SAM7SE, MCU_AT91SAM7X and MCU_AT91SAM9XE. The same file, when
> generated automatically from a Windows installation defines only
> MCU_AT91R40008 and MCU_AT91.
>
> I have also noticed other disparities between the build trees generated
> in Linux and Windows. Is this normal? Shouldn't they be the same? If
> not, why?
>
> As a side note, I can compile the build tree generated from Windows in
> my linux machine
>
> Just in case it is useful, I have noticed differences also in the
> following automatically generated files:
> nut-bld/include/cfg/ahdlc.h
> nut-bld/include/cfg/audio.h
> nut-bld/include/cfg/audio.h
> nut-bld/include/cfg/eeprom.h
> nut-bld/include/cfg/memory.h
>
> So, as usual, am I missing something?
>
> Thanks in advance!
>
> José
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

Different automatically generated build trees in Linux and Windows for NutOS 4.8 (was Re: "US_PIOA_PINS_A" redefined)

2009-11-04T05:07:25Z

Hello all.

I am still struggling to compile a fresh ethernut-4.8.* in my linux.

The previous short thread can be found at
http://groups.google.com/group/osdeve_mirror_rtos_en-nut-discussion/browse_frm/thread/20c243fe22b49b5b/f36336950173ab7e?hl=en&lnk=gst&q=%22US_PIOA_PINS_A%22+redefined#f36336950173ab7e

This time I tried 4.8.5, with the same result:
-------
/home/jose/ethernut2/ethernut-4.8.5/arch/arm/dev/usart0at91.c:229:1:
error: "US_PIOA_PINS_A" redefined
/home/jose/ethernut2/ethernut-4.8.5/arch/arm/dev/usart0at91.c:215:1:
error: this is the location of the previous definition
-------

As Marcus Jansson kindly pointed, it seems to be due to having multiple
MCUs defined. Let me recall that I have not modified the sources, I am
using a fresh downloaded ethernut-4.8.5 package.

Trying to dig into this I noticed that the automatically generated
nut-bld/include/cfg/arch.h has, among PLATFORM and ARM_GCC, the
following MCUs defined: MCU_AT91R40008, MCU_AT91, MCU_AT91SAM7S,
MCU_AT91SAM7SE, MCU_AT91SAM7X and MCU_AT91SAM9XE. The same file, when
generated automatically from a Windows installation defines only
MCU_AT91R40008 and MCU_AT91.

I have also noticed other disparities between the build trees generated
in Linux and Windows. Is this normal? Shouldn't they be the same? If
not, why?

As a side note, I can compile the build tree generated from Windows in
my linux machine

Just in case it is useful, I have noticed differences also in the
following automatically generated files:
nut-bld/include/cfg/ahdlc.h
nut-bld/include/cfg/audio.h
nut-bld/include/cfg/audio.h
nut-bld/include/cfg/eeprom.h
nut-bld/include/cfg/memory.h

So, as usual, am I missing something?

Thanks in advance!

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

Re: Slight problem with UDP

2009-11-03T04:34:35Z

Hi Ole,

Thanks for your reply,

>In your current configuration it might be possible that the first UDP
>packet is send out before the arp challenge / response is finished, so
>your pc does not have a complete arp table right at the beginning of
>your program... (on the pc side).

So you think that it's a pc-side problem?
things should go like this:

en pc

ARP whois pc ?
ARPr here i am
UDP take this one !
ARP whois en ?
ARP let me think ...
uhmm ... no one replies drop that %$%ih
ARPr here i am nice to meet you !

then, they live long and prosper ...

I have not much debugging aid, but i have tried to
"UDP flood" my server, with another pc, and i have lost
no first packet, so it seems more a "slow" reply from ethernut

maybe en ARP replying task is switched too early, before completing
ARP challenge so UDP packet is sent too early to the server

I am not that deep into ARP, so i don't know whether the responding
side knows if the querying side has got his reply or if all is left
to timeouts

next days i will setup a more deep test, anyway this seems a well
known behaviour, with a workaround too ;-) !

sorry for the spam at the end of my messages

Ciao!
Paolo

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

Re: NutOS serial driver

2009-11-03T02:36:11Z

Hi Jason,

> I am using the NutOS v4.8.0. The application that I am writing needs to
> received 2070 bytes in one shot and also transmit 4096 bytes in one
> shot via RS232, I enabled interruptions to detect the end of the
> packet when I received data. If I increase the USART_RXBUFSIZ to 3072
> bytes and the USART_TXBUFSIZ tp 5120. Do I have to have any
> considerations? Will The nutOS v4.8.0 crush due to this changes?

Some time ago we just had a discussion concerning a bug in the serial
driver implementation triggered when changing the rx / tx buffer size.

If you like to do so you should always also set the hight and low
watermark of the rx an tx buffers. Otherwise you might get corrupted
data.

At least the size of your buffers is only limited by the available free
memory. As Ulrich just mentioned you should better take into account if
you realy need such large buffers.

If you want to check if the buffer is empty (tx as completed) you can
use the following code:

int cycle = 0;
uint32_t parm;

do {
_ioctl(_fileno(uart0), UART_GETSTATUS, &parm);
NutSleep(10);
} while (!(parm & UART_TXBUFFEREMPTY) || (cycle > 1000));

Btw: Instead of sleeping you could do something usefull too...

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: Slight problem with UDP

2009-11-02T13:33:45Z

Hi!

> While playing with "icmp-udp.c", after some packet sniffing with
> FreeBSD's tcpdump i have noticed that the first packet sent by the
> ethernut was regularly lost.
> [...]
> The issue seem to be somehow ARP related, just adding a slight
> ( > 300 ms ) delay before start sending UDP packets to the server
> seem solve the problem ...

Indeed I noticed similar behaviour some time ago with the tftp
bootloader implementations of NutOS. The arp implementation did not
include a arp response. When the PC had sended an arp request and did
not get any reponse, the arp entry was deleted and no more packets were
accepted by the pc.

In your current configuration it might be possible that the first UDP
packet is send out before the arp challenge / response is finished, so
your pc does not have a complete arp table right at the beginning of
your program... (on the pc side).

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

Slight problem with UDP

2009-11-02T04:34:50Z

Hello world,

First of all let me make my congratulations to all those who
are supporting the EN/NutOS project ...

Now, ... since i am quite new to ethernut i am just compiling
example applications (UDP and rs232),
ethernut 4.8.5 compiled with WinAVR under Window$ XP and board rev 1.3h

While playing with "icmp-udp.c", after some packet sniffing with
FreeBSD's tcpdump i have noticed that the first packet sent by the
ethernut was regularly lost.

Wince i am absolutely trusting with FreeBSD's TCP/IP ;-)
and ethernut was tied to a network of just 4 machines the
only culprit had to be ethernut :( ...

The issue seem to be somehow ARP related, just adding a slight
( > 300 ms ) delay before start sending UDP packets to the server
seem solve the problem ...

...

if (NutThreadCreate("RCV", UDPReceiver, (void*)socket, 1024) == 0) {
puts("Could not start receiver thread\r\n");
puts("Demo halted...\r\n");
while (1);
} else {
puts("Receiver thread started\r\n");
}

puts("Starting echo test (1 packet / second)\r\n");

ip_udp_echo = inet_addr(UDP_ECHO_IP);
packet_nr = 0;

->>> NutSleep(500);

for(;;) {
packet_nr ++;

...

Maybe i am wrong and this could be related to some TCP/IP configuration
that i have missed while building NutOS ?

Netwotk(general) -> TCP -> state machine stack
Netwotk(general) -> ARP -> <various options>

...

Any hint welcome

Ciao!
Paolo

--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Prova il servizio di Email Marketing di Email.it, incrementi la visibilita' della tua azienda e trovi nuovi clienti.
* Liste a partire da 10.000 contatti per soli 250 Euro
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8351&d=2-11
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: DHCP Failure on Renew

2009-11-02T01:06:19Z

Hello,

Ulrich wrote:

>How did you find out about that problem? Is there a backup DHCP in your
>network and the primary failed? Or did you simply leave the box in you
>network that long, that the lease expired? I think I remember, that the
>EIR did not work after lying around a longer time playing musik. I
>simply reset it and it worked again for days. But I never tried to find
>out why and I don't know the lease-time the Fritbox assigns to it's
>clients.

>I'll try that DHCP lease timeout in the next few days. Never checked
>that, as my problems were at another situation.

Well, I simply setup an DHCP server with a 1 hour lease time - the system
crash after half an hour so no big challenge.

As far as I can see the DHCP code is a little overcomplicated and the main
codes readability could have benefited from being stuck in a switch/case
construct.

Any way; I found two problematic points in the code so far. The First, in
line 1708 will cause the DhcpBroadcastRequest call, which is essential for
keeping the state machine running, to not being called as at the time that
this is executed it is already '<=' leaseTime.

So changing the condition to < might help. But also the DhcpBroadcastRequest
should, in my opinion, always be called to make sure the state machine does
not go stale - hence remove the 'else' in line 1714. Also, recalling
NutGetSeconds() again and again throughout the routine also seems like a
waste and induces a possible race condition as the second might just tick
over between to calls.

else if (dhcpState == DHCPST_RENEWING) {
retries++;
if (tmo / 1000 > dhcpConfig->dyn_rebindTime - (NutGetSeconds() -
leaseTime)) {
tmo = dhcpConfig->dyn_rebindTime - (NutGetSeconds() -
leaseTime) * 1000;
}
1708: if (dhcpConfig->dyn_rebindTime <= NutGetSeconds() - leaseTime) {
retries = 0;
dhcpState = DHCPST_REBINDING;
}
/* Send a request to our leasing server. We must not include
the server identifier. */
else if (DhcpSendRequest(sock, dhcpConfig->dyn_sid, bp, xid,
dhcpConfig->dyn_yiaddr, dhcpConfig->dyn_yiaddr, 0, secs) <
0) {
/* Unicast transmit error. */
retries = 0;
dhcpState = DHCPST_REBINDING;

A bit lower we encounter the same. Here, I feel that the whole leaseTime
'if' is completely de-placed

else if (dhcpState == DHCPST_REBINDING) {
retries++;
if (tmo > dhcpConfig->dyn_rebindTime - (NutGetSeconds() -
leaseTime)) {
tmo = dhcpConfig->dyn_rebindTime - NutGetSeconds() -
leaseTime;
}
1746: if (dhcpConfig->dyn_rebindTime <= NutGetSeconds() - leaseTime) {
retries = 0;
dhcpState = DHCPST_REBINDING;
}
/* Broadcast a request for our previous configuration. We
must not include a server identifier. */
else if (DhcpBroadcastRequest(sock, bp, xid,
dhcpConfig->dyn_yiaddr, dhcpConfig->dyn_yiaddr, 0, secs) < 0) {
/* Fatal transmit error on broadcast. Give up. */
dhcpState = DHCPST_IDLE;

My current implementation with simply removing both 'else' works like a
charm and I have not had any negative side effects. But, my plan is fully
understand the routine and then to re-write and simplify the routine...

Cu,
Michael

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

Re: NutTcpAccept blocks the tread

2009-10-31T16:45:33Z

Hi!

I had that problem on a serial interface protocol... Establishing
communication, doing a handshake and setup and then run a protocol
everything with different timings and second and third part with
timeout, first one without...

I solved it with a simple thing:
I wrote a minimalistic thread waiting for an event on th serial line. If
the event happened, the thread does an initial handshake and creates the
second thread and terminates itself directly after.
The second thread initiates telegrams and creates a third thread,
decoding the telegrams. If the third thread detects communication
problems, it terminates itself and the second thread tries to recover.
If that fails, the second thread starts the first one and terminates itself.
Works wonderful!

Now to your problem:
How if you write a small thread for waiting for a tcp connection. You
can start this thread several times, giving different parameters
regarding the ports and interfaces to serve. You hand over a parameter
pointing to the stream too.

Then you write a second thread, serving the data when an connection has
been established. This thread can have timeout handling and the other
things you like. The state-machine in the main loop can detect if the
thread has a connection or not by a variable or something.

Now, I would not start the second thread as I do not see, why one single
state machine does everything, but if you like, start 5 of the first and
5 of the second threads.

If a connection is accepted, the first type of threads detects it,
accepts the connection and does a NutEventPost on the related
data-thread. While normally a timeout will result in NutEventWait() ==
-1, now it will return 0 and you know that you have been waked by
incoming data, so handle it.

I would have started the data-threads in the accept-threads and handed
over the needed pointers to the stream as a parameter. You need to
define a message-box or use some global variables for that. Both should
work and does not need a rework of the network system.

The accept-threads can also get some more timeout handling. If the
data-threads see, that a connection is closed, they can do a
NutEventPost() on the accept-threads. But that could lead to a stuck
thread if there is an unclean connection abort. So the accept threads
could check some counters or so to assure that the corresponding
data-thread is working well. If they get awake because NutEventWait()
returns -1 they check and handle erroneous conditions, if returned 0 the
await a new connection.

If you change to my implementation, the accept-threads will create
corresponding data-threads and vice versa. The main loop will check if
either accept- or data-thread exists and works well. If not it will
reboot or try to kill the threads ( never checked if that is possible
with Nut/OS) and restart them.

Regards,
Ulrich

Nathan Moore schrieb:

> Hey Harald,
>
>> Considered, that NutTcpPassiveOpenEvent had been changed following your
>> suggestion, the application will use the following pseudo code:
>>
>> for (;;) {
>> CreateSocket();
>> SocketOption(Set read timeout);
>> while (NutTcpAccept()) {
>> /* Timout, do something else,
>> ** but do not sleep. */
>> }
>> /* Handle the connection. */
>> ...
>> /* Finally */
>> DestroySocket();
>> }
>>
>> Is that what you meant?
>
>
> Yes. It could check a variable or something and never open the window of
> not listening to that port.
> If it did sleep there it would still work, but would introduce the
> possibility that you wouldn't be listening for a moment..
>
>
> Nathan
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

Re: NutOS serial driver

2009-10-31T16:01:31Z

Hi!

Jason Bourne schrieb:

> Hi,
>
>
>
> I am using the NutOS v4.8.0. The application that I am writing needs
> to received 2070 bytes in one shot and also transmit 4096 bytes in
> one shot via RS232, I enabled interruptions to detect the end of the
> packet when I received data. If I increase the USART_RXBUFSIZ to 3072
> bytes and the USART_TXBUFSIZ tp 5120. Do I have to have any
> considerations? Will The nutOS v4.8.0 crush due to this changes?
>

Hard to tell, as you don't tell on what target you're running that.
If you use an ATmega128 it will crash as there is not enough memory. If
you use an ARM7 based system with 32k+ memory it should work.

I never saw a serial protocol that needed to be read at once in such a
big trunk. Normally you need data part by part and can work with each
part. If the data is not to be interrupted by buffer full conditions,
you only have to ensure, that the primary serial buffers are big enough
to fetch data without overrun while you work with the already received
data elsewhere before you pick the next part from the input buffer.

So you can interpret the data as it comes in part by part and sort it to
the structs where it should go. The input buffer takes care, that you
don't loose anything while you're busy decoding it.

Same with the output. If you send data, it will be placed into the
output buffer. If the buffer is full, your sending thread will be
blocked until there is some space in the buffer again ( look at high an
low watermark settings). If you'd like to have a continuous flow of
data, lower the output buffer size and set the output thread to a higher
priority and it will keep the output buffer full.

If you have an idea of how long your output thread needs for preparing
the data, you can use the high- and low-watermark system to. Let one of
these guys trigger your thread to prepare the next data just in time.

With that you need only small buffers and keep up a continuous data flow.

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

NutOS serial driver

2009-10-31T11:35:57Z

Hi,

I am using the NutOS v4.8.0. The application that I am writing needs to received 2070 bytes in one shot and also transmit 4096 bytes in one shot via RS232, I enabled interruptions to detect the end of the packet when I received data. If I increase the USART_RXBUFSIZ to 3072 bytes and the USART_TXBUFSIZ tp 5120. Do I have to have any considerations? Will The nutOS v4.8.0 crush due to this changes?

Thank you

Juan

_________________________________________________________________
Windows 7: It works the way you want. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:102009
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Dual rs232<->Ethernet

2009-10-30T12:31:38Z

Hi!

Yes, if you take a look at the previous discussion of the last few
weeks, you'll see, that there are some problems existing in the TCP/IP
stack.
But what you tell is that connections are not completely handled, as a
TCP COnnection may break at any time. So try to find a good point where
to monitor that situation and clean up the system to a default where it
accepts new data and connection.

But without code it's hard to tell.

Regards, Ulrich
asdus schrieb:

> Yep, you're right. But rs232d primer have some troubles.
> Yes, it's have buffers to resolve different speed problems, but
> connection stucks, if ethernet client disconnect unclean, and,
> sometimes, i'm have strange data freezes, when i receive sended data
> only on next connection.
>
> 2009/10/30 Ulrich Prinz <uprinz2@...>:
>> I am not sure, if I understand that correctly:
>> You'd like to communicate with two RS232 ports via TCP/IP.
>> In nut/app/rs232d there is a demo for doing that with one single port.
>> So you can duplicate the THREAD and assign the second one to a different
>> port. As a connection like that cannot be shared, only one client can
>> access one RS232 port. So you do not need to take care of launching
>> several threads per port.
>>
>> To access GPIOs of the CPU there are different options. You can watch
>> the RS322 communication an catch special commands, that are not routet
>> to the RS232 port but are used to control or read GPIOs.
>>
>> Or you can launch a third server thread that controls the GPIOs.
>>
>> If your code doesn't work, you can post parts of the code in here, so we
>> can help.
>>
>> Regards
>> Ulrich
>>
>> asdus schrieb:
>>> Hi all.
>>> For my home automation i need to use 2 rs232<->ethernet converters
>>> I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
>>> TCP Server and Serial Port Monitor examples.
>>> Using that i need to do this in dedicated threads, because i'm use
>>> other ethernut's digital pins to get home events. All my tries fails,
>>> i have lags using my remote rs232's.
>>>
>>> Can anyone with code or part of code, that's can help me to resolve my
>>> problem? Great thanks!
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

Re: Dual rs232<->Ethernet

2009-10-30T01:16:38Z

Yep, you're right. But rs232d primer have some troubles.
Yes, it's have buffers to resolve different speed problems, but
connection stucks, if ethernet client disconnect unclean, and,
sometimes, i'm have strange data freezes, when i receive sended data
only on next connection.

2009/10/30 Ulrich Prinz <uprinz2@...>:

> I am not sure, if I understand that correctly:
> You'd like to communicate with two RS232 ports via TCP/IP.
> In nut/app/rs232d there is a demo for doing that with one single port.
> So you can duplicate the THREAD and assign the second one to a different
> port. As a connection like that cannot be shared, only one client can
> access one RS232 port. So you do not need to take care of launching
> several threads per port.
>
> To access GPIOs of the CPU there are different options. You can watch
> the RS322 communication an catch special commands, that are not routet
> to the RS232 port but are used to control or read GPIOs.
>
> Or you can launch a third server thread that controls the GPIOs.
>
> If your code doesn't work, you can post parts of the code in here, so we
> can help.
>
> Regards
> Ulrich
>
> asdus schrieb:
>> Hi all.
>> For my home automation i need to use 2 rs232<->ethernet converters
>> I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
>> TCP Server and Serial Port Monitor examples.
>> Using that i need to do this in dedicated threads, because i'm use
>> other ethernut's digital pins to get home events. All my tries fails,
>> i have lags using my remote rs232's.
>>
>> Can anyone with code or part of code, that's can help me to resolve my
>> problem? Great thanks!

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

Re: DHCP Failure on Renew

2009-10-29T16:53:34Z

Hi!

Hm, I am actually working in that direction...
My Problem with DHCP was, that it did not work if you change the network
completely, i.e. unplug the system at home with 192.168.3.0/24 and plug
it in at work with 10.201.32.0/16.

In my opinion there are several problems buriedin DHCP, but let's stick
to the one you saw...

I found this in line 1773:
else if (dhcpState == DHCPST_REBINDING) {
retries++;
if (tmo > dhcpConfig->dyn_rebindTime - (NutGetSeconds() -
leaseTime)) {
tmo = dhcpConfig->dyn_rebindTime - NutGetSeconds() -
leaseTime;
}
if (dhcpConfig->dyn_rebindTime <= NutGetSeconds() -
leaseTime) {
retries = 0;
dhcpState = DHCPST_REBINDING;
}
/* Broadcast a request for our previous configuration. We
must not include a server identifier. */
else if (DhcpBroadcastRequest(sock, bp, xid,
dhcpConfig->dyn_yiaddr, dhcpConfig->dyn_yiaddr, 0, secs) < 0) {

This looks a bit like if the DHCPST_REBINDING is timed out, it stays in
DHCPST_REBINDING in the second if()...
Looks like someone tried to escape this situation by checking for
retries, but the if( retries > n) 'out of here' is missing.
On the other hand, there is a timeout and if that is over one needs to
get out of that loop instead of staying inside.

How did you find out about that problem? Is there a backup DHCP in your
network and the primary failed? Or did you simply leave the box in you
network that long, that the lease expired? I think I remember, that the
EIR did not work after lying around a longer time playing musik. I
simply reset it and it worked again for days. But I never tried to find
out why and I don't know the lease-time the Fritbox assigns to it's
clients.

I'll try that DHCP lease timeout in the next few days. Never checked
that, as my problems were at another situation.

By the way, I modified the DM9000 driver for the EIR and now I can
switch networks with different subnets and subnet-sizes and I get a dhcp
lease... Yes, ouch. Never expected the problem to be that far down in
the OSI model :)

Regards
Ulrich

Michael Jones schrieb:

> Hello,
>
> We have been having problems with DHCP enabled client dying after half lease
> time for quite a while (Also reported by Ulrich a few days ago).
>
> My observations are that the DHCP thread gets stuck in the DHCPST_REBINDING
> state and never sends the request nor yields to any other thread.
>
> I'm still trying to understand to whole state machine, but perhaps somebody
> could look at the "else" in dhcpc.c (trunk), line 1714 - IMHO that "else"
> should not be there. Also, I'm not quite sure how the DHCPST_REBINDING state
> should conclude once it has been entered.
>
> cu,
> Michael
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

Re: Dual rs232<->Ethernet

2009-10-29T16:21:37Z

Hi!

I am not sure, if I understand that correctly:
You'd like to communicate with two RS232 ports via TCP/IP.
In nut/app/rs232d there is a demo for doing that with one single port.
So you can duplicate the THREAD and assign the second one to a different
port. As a connection like that cannot be shared, only one client can
access one RS232 port. So you do not need to take care of launching
several threads per port.

To access GPIOs of the CPU there are different options. You can watch
the RS322 communication an catch special commands, that are not routet
to the RS232 port but are used to control or read GPIOs.

Or you can launch a third server thread that controls the GPIOs.

If your code doesn't work, you can post parts of the code in here, so we
can help.

Regards
Ulrich

asdus schrieb:

> Hi all.
> For my home automation i need to use 2 rs232<->ethernet converters
> I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
> TCP Server and Serial Port Monitor examples.
> Using that i need to do this in dedicated threads, because i'm use
> other ethernut's digital pins to get home events. All my tries fails,
> i have lags using my remote rs232's.
>
> Can anyone with code or part of code, that's can help me to resolve my
> problem? Great thanks!
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

Re: NutUdpSendTo taking too long

2009-10-29T15:47:21Z

Hello Nathan, and thanks for the explanation. It was a shortcut to the
code that explains it. My friend was called "arpcache.c"

I have still some questions.

Nathan Moore escribió:
> Hey José,
> When you send a IP packet over ethernet you have to know the MAC
> address of the recipient. To find this out the ARP (Address Resolution
> Protocol) cache is examined. If no entry for the destination IP address
> is in the ARP cache then an ARP request must be sent over the
> local ethernet and then you have to wait for an ARP reply. If no one
> is there with that IP address then you just wait until you finally give up.
> In NutOS the sending thread is blocked until the IP packet is either sent
> or something goes wrong (in this case no ARP reply).

And in that case the no ARP reply is not considered an error, so
NutUdpSenTo will peacefully return 0. So it seems to me that for an
application there is no straight way to detect when an ARP entry has
been deteled. Perhaps calling directly ArpCacheLookup, or even
NutArpCacheQuery? Anything against this that I should be aware of?

Another way to solve this issue, I guess, could be to mark the ARP entry
as permanent, so it will not be flushed. Is this correct? It seems that
it would require to manipulate the ARP entry manually, as I couldn't
find any function to add/manipulate entries. Anything against this that
I should be aware of? In my case it is assumed that the IP of the
machine that the Ethernut sends the UDP packets to has always the same
private IP

Regards!
José

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

Re: NutUdpSendTo taking too long

2009-10-29T10:51:26Z

Hey José,
When you send a IP packet over ethernet you have to know the MAC
address of the recipient. To find this out the ARP (Address Resolution
Protocol) cache is examined. If no entry for the destination IP address
is in the ARP cache then an ARP request must be sent over the
local ethernet and then you have to wait for an ARP reply. If no one
is there with that IP address then you just wait until you finally give up.
In NutOS the sending thread is blocked until the IP packet is either sent
or something goes wrong (in this case no ARP reply).

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

NutUdpSendTo taking too long

2009-10-29T10:02:19Z

Hello all.

We have found one weird behaviour of NutUdpSendTo. Basically the problem
is the following.

If we put our Ethernut3 (with NutOS 4.6.4) to send UDP packets in a
network that does NOT have a computer with the IP that the UDP packets
are sent to, after some time (about 15 minutes) the Ethernut gets into a
state where every single execution of NutUdpSendTo takes about 500ms. We
can also see that in this state the microcontroller spends most of the
time idling, which suggests that there is a wait process somewhere. To
my poor understanding, sending a UDP packet is something like simply
dropping the packet into the network, not waiting for anything.

After this, if a computer with the target IP "appears" (in linux I
configure an ip alias), the situation comes back normal immediately,
where it takes usually in the order of milliseconds to execute NutUdpSendTo.

This situation seems to be reproducible. A simple while loop sending UPD
packets and a bit of patience makes the issue to show up. We measure
time by setting pins up and down and with an oscilloscope/logic
analyser. The basic code that we use is the following

-----------------------
#define MY_MAC "\x00\x06\x98\x30\x00\x35"
#define MY_IPADDR "192.168.0.100"
#define MY_IPMASK "255.255.255.0"

int main(void)
{
u_long ip_addr = inet_addr(MY_IPADDR);
u_long ip_mask = inet_addr(MY_IPMASK);
u_char mac[] = MY_MAC;
UDPSOCKET *sock=NULL;
char buf;

DEBUGPINS_INIT;

/* Initialize the serial port */
NutRegisterDevice(&DEV_UART0, 0, 0);
freopen("uart0", "r+", stdout);
_ioctl(_fileno(stdout), UART_SETSPEED, &baud);
printf("\n\nNut/OS %s\n", NutVersionString());

/* Register the tracer and start the terminal */
btn_terminal_init(stdout, "[udp]$");
btn_terminal_register_cmd("trace",NutTraceTerminal);
btn_terminal_run(BTN_TERMINAL_FORK, 0);

/* Register Ethernet controller */
NutRegisterDevice(&DEV_ETHER, 0, 0);
NutNetIfConfig("eth0", mac, ip_addr, ip_mask);
sock = NutUdpCreateSocket(LOCAL_PORT);
if (sock==0)
{
DEBUGPINS_SETHIGH(2); //Set the debug pin 2 up
}
ip_addr=inet_addr(REMOTE_IP);
while (1)
{
DEBUGPINS_SETHIGH(0); //Set the debug pin 0 up
if (NutUdpSendTo(sock, ip_addr, REMOTE_PORT, &buf, 1) == -1)
{
DEBUGPINS_SETHIGH(3);
NutSleep(200);
DEBUGPINS_SETLOW(3);
}
DEBUGPINS_SETLOW(0); //Set the debug pin 0 low
buf++;
}
}
-----------------------

where the DEBUGPINS_SETHIGH(X) is a macro to put the Xth pin of our
debug connector to 1, and similar with the rest of macros. The pin 1 is
used to indicate when the micro is in the idle thread, and thus cannot
be seen in the code here, as it is in the NutOS sources. As you can see
we are able to use the tracer also in Ethernut3 (thanks to the
modifications of Ernst Stippl) through the btn-terminal for easily
getting the traces. If required we can provide sample traces and
pictures of the measurements with the scope. We can also provide all the
files required to run this code.

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

Re: Bootloader

2009-10-29T04:29:06Z

I will appriciate any help from you. I've written simple program that just jump to 4000 location. At this addres I placed program that blinks leds. It works, so I tries to place nutos under 4000 addres. But this time nutos won't start. I changed nutos ld file like this:

MEMORY
{
rom (rx) : org = 0x000004000, len = 240k
ram (rw) : org = 0x00200000, len = 64k
}

Any ideas? Or maybe what needs to be done before jumping? how to perform a jump? What to change in nutos?

Re: SOAP client for Ethernut 3.0?

2009-10-27T15:24:22Z

Javier Longares wrote:
> Hi folks,
>
> I'm looking for making a SOAP client with Ethernut 3.0E board and I would
> know if there is some souce code or some open source project which could led
> my firsts steps.
>
> Of course, if you know a SOAP for this board or you like toi make me some
> suggestion I'll be very glad to hear you.

In my experience with SOAP my advice is this:
- If you can avoid using it, do! It's bloated, overly complex, and
everyone implements their own sub-set of the spec, making
interoperability challenging, at best.

If you want your devices to talk to an existing SOAP service, fair
enough. Consider using pre-generated request templates, instead of
using a full XML generating lib.

On the parsing side, I think you'd be hard-pressed to get a fully
compliant XML parser, though you should be able to get away with a
light, SAX-like system.

If you can choose, choose to NOT use SOAP. If you control both server
and client, why not use regular HTTP POST? If you need structured data,
I understand JSON can be very easy to parse with regex.

--
Curtis Maloney

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

DHCP Failure on Renew

2009-10-27T15:10:36Z

Hello,

We have been having problems with DHCP enabled client dying after half lease
time for quite a while (Also reported by Ulrich a few days ago).

My observations are that the DHCP thread gets stuck in the DHCPST_REBINDING
state and never sends the request nor yields to any other thread.

I'm still trying to understand to whole state machine, but perhaps somebody
could look at the "else" in dhcpc.c (trunk), line 1714 - IMHO that "else"
should not be there. Also, I'm not quite sure how the DHCPST_REBINDING state
should conclude once it has been entered.

cu,
Michael

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

Re: NutCOnf/Qt

2009-10-27T08:33:56Z

Hi,

I've updated the qnutconf in svn. It is now able to save the
settings dialog info to the registry and even build the NutOS
libraries. Everything is very "alpha" at this point, but it now
actually does something *hopefully* usefull :)

If anyone wants to check out and care to comment, it would be
appreciated. I'm outputing the full build log to the log window. I'm
considering offering at the Settings dialog some sort of verbose
filter. Perhaps even just invoke make and make -s depending on the
verbosity level. I did some experiences with make -j5 but it didn't
improve the buildtime, or my CPU utilization on my quad-core, so I
dropped it.

PS: I do realize it looks ugly. I guess I need to fix the images
folder to png or something like that.

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

SOAP client for Ethernut 3.0?

2009-10-27T05:45:18Z

Hi folks,

I'm looking for making a SOAP client with Ethernut 3.0E board and I would
know if there is some souce code or some open source project which could led
my firsts steps.

Of course, if you know a SOAP for this board or you like toi make me some
suggestion I'll be very glad to hear you.

Best regards,

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

Dual rs232<->Ethernet

2009-10-27T04:33:35Z

Hi all.
For my home automation i need to use 2 rs232<->ethernet converters
I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
TCP Server and Serial Port Monitor examples.
Using that i need to do this in dedicated threads, because i'm use
other ethernut's digital pins to get home events. All my tries fails,
i have lags using my remote rs232's.

Can anyone with code or part of code, that's can help me to resolve my
problem? Great thanks!
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Measuring idle time

2009-10-26T08:22:36Z

Hello all.

>
> We are debugging one application in Ethernut3, and we want to measure
> the time that the micro spends doing some tasks. For that we are setting
> different pins up and down and measuring times with the oscilloscope.
>
> To measure the idle time we are setting up one of the pins during the
> execution of the idle thread. I am sure that many people have been
> thinking about/doing this, so I wonder if NutOS provides some kind of
> debug option or mechanism to do this already.
>

I did this once but there was no support in Nut for it.
I only had 3 gpio (LEDs in this case) available, but had less than 9 threads
including the idle
thread, so I added a uint8_t to the thread control block to represent the
LED pattern.
I also added code in NutThreadCreate to count how many times it had been
called and store that
in each thread block.
Then I added code in task switching to set all of my gpio to 0 while doing
thread switching and
set them to the pattern of the runningThread when a new thread had been
scheduled based on
the variable I had added to the thread control block.
I then added code in my main thread to print out the thread names and their
LED pattern after all
my threads were created but before the main thread entered it's normal
running state (loop).
idle = 001
main = 010
TcpSm = 011
A = 100
B = 101
C = 110

Task switching would be 000
If you have enough gpio available I would suggest strongly using only a
single bit per thread rather
than a bit pattern since it's easier to scope and measure.

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

Measuring idle time

2009-10-26T07:54:06Z

Hello all.

We are debugging one application in Ethernut3, and we want to measure
the time that the micro spends doing some tasks. For that we are setting
different pins up and down and measuring times with the oscilloscope.

To measure the idle time we are setting up one of the pins during the
execution of the idle thread. I am sure that many people have been
thinking about/doing this, so I wonder if NutOS provides some kind of
debug option or mechanism to do this already.

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