Nabble - MicroControllers

Top 20 downloads from Tektronix

2009-11-12T13:50:33Z

http://www.tek.com/learning/top20/
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [EE]

Re: Windows 7 as NFS server

2009-11-12T13:23:36Z

On Thu, 2009-11-12 at 16:42 -0400, M.L. wrote:

> On Thu, Nov 12, 2009 at 3:46 PM, solarwind <x.solarwind.x@...> wrote:
> > Hey all, does anyone know of free NFS software for windows 7?
> >
>
> Aside from being a terrible idea from a security standpoint..
> Windows back in the day had an optional unix migration component IIRC.
> It supposedly had an NFS server and client.
>
> If I had to do this I would first investigate using utilities compiled
> for Cygwin. I would probably figure out it's a bad idea and use native
> windows shares and Samba on the *nix side, or WebDAV ("web folders")
>
> In practice when I need to mount a windows share on a linux system
> I've rarely had trouble using Samba as a client.

I was never able to figure out how to get a Linux machine to connect to
a Vista machine smb share reliably, and haven't been able at all to
connect a Linux machine to Win7 smb share. I'm sure there's some trick,
I just haven't found it.

As a stop gap I installed cygwin and sshd so I could at least get at my
files over sshfs, not ideal, but better then nothing.

TTYL

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: [TECH] Questions about water jets

2009-11-12T12:56:05Z

Even Gargoyle ads knows :-)

http://www.gardnerdenverproducts.com/WaterJetting/Default.aspx

5000-50,000 psi for theirs

Nozzles
http://www.gardnerdenverproducts.com/Microsite_ProductNavigation.aspx?id=2494

2009/11/13 Russell McMahon <apptechnz@...>

> > #1 What pressure range do they operate at ?
> > #2 Does the water stream contain abrasives ?
> > #3 What kind of material is used for the nozzle ?
> 1. Gargoyle knows.
> 2. Gargoyle knows.
> 3. Gargoyle knows.
>
> From fading memory.
> Thousands of psi (insert own unit conversion here).
> Almost invariaby - carborundum / saphire often.
> ?Saphire? (???)(Gargoyle knows).
>
>
> Russell
>
>
>
>
> 2009/11/13 YES NOPE9 <yes@...>
>
> #1 What pressure range do they operate at ?
>> #2 Does the water stream contain abrasives ?
>> #3 What kind of material is used for the nozzle ?
>>
>> Regards
>> Gus
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: [TECH] Questions about water jets

2009-11-12T12:49:34Z

At 02:49 PM 12/11/2009, you wrote:

>#2 Does the water stream contain abrasives ?

Depends on what is to be cut. For cutting metals and ceramics, yes.
For foam, cloth and other soft stuff, generally no..

Google is your friend on this sort of thing..

Best regards,

Spehro Pefhany --"it's the network..." "The Journey is the reward"
speff@... Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: Windows 7 as NFS server

2009-11-12T12:42:32Z

On Thu, Nov 12, 2009 at 3:46 PM, solarwind <x.solarwind.x@...> wrote:
> Hey all, does anyone know of free NFS software for windows 7?
>

Aside from being a terrible idea from a security standpoint..
Windows back in the day had an optional unix migration component IIRC.
It supposedly had an NFS server and client.

If I had to do this I would first investigate using utilities compiled
for Cygwin. I would probably figure out it's a bad idea and use native
windows shares and Samba on the *nix side, or WebDAV ("web folders")

In practice when I need to mount a windows share on a linux system
I've rarely had trouble using Samba as a client.

--
Martin K.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

How to gain much money quickly

2009-11-12T12:41:18Z

http://www.Wholesalers-Net.c.la

[Non-text portions of this message have been removed]

From forum: OOPic

Re: [TECH] Questions about water jets

2009-11-12T12:26:48Z

On Thu, 12 Nov 2009 15:17:08 -0500, "Olin Lathrop" said:
> YES NOPE9 wrote:
> > #1 What pressure range do they operate at ?
> > #2 Does the water stream contain abrasives ?
> > #3 What kind of material is used for the nozzle ?
>
> Sorry, we're not running a contest currently for the worst formed or most
> ambiguous question.

Hi Olin, welcome back :)

Cheers,

Bob

--
http://www.fastmail.fm - Access your email from home and the web

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: TCP connection to fixe IP

2009-11-12T12:24:13Z

Hi Gilles,

I am not a moderator, but I have to interrupt because some clarification
is needed.

Please specify the _complete_ configuration of the networks and devices.
Otherwise no one can help.

A device on a network has 3 parameters not two, a Router has more.

So to understand your problem we need:
EtherNut IP
EtherNut Netmask
EtherNut Gateway

Your routers parameters for the internal network:
IP
Netmask

If your Router spans a network of IP/Netmask 192.168.0.254/255.255.0.0
and your EtherNut has a IP/Netmask of 192.168.1.86/255.255.0.0
and this does'nt work, Nut/OS has a problem.

If _one_or_both_ of these devices has/have a netmask of 255.255.255.0
like it is defined for the Class-C Range 192.168.x.y, you have a problem
with the configuration.
Remember that, again, 192.168.x.y is an IP-Range defined for 256 Class-C
networks what means, that there should be a 255.255.255.0 netmask. Very
often Home-Routers are assuming an Class-C Netmask if they are assigned
to 192.168.x.y. networks.
I know, that 10.x.y.z is used to be 1 Class-A network, where 255.0.0.0
is the right netmask. I forgot about the Class-B, i.e. 255.255.0.0

As all these networks specify numberings for internal networks, everyone
is free to use it as specified... or not.

If you use a Class-B network and there is no router in between your
ethernut on 192.168.1.x and your internet-router on 192.168.0.y then you
have to set the netmask in every device on both networks to 255.255.0.0

I hope, you can clarify the situation, so we are talking about the same
data to find the bug.

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.

Best regards,
Ulrich

Gilles schrieb:

>
>
> Hi all,
>
> I have developed a piece of code to establish a dialog between my ARM9 board
> and a PC in 2 different location.(2 different IP fix addresses)
>
>
>
> When the PC establish the TCP link , the ARM9 receive and respond to the
> TCP frame correctly.
>
>
>
> If I try to establish the TCP dialog starting from the ARM9, it fails on the
> NutTcpConnect(sock1,dest_addr, PortSend)
>
>
>
> All is good if I stay inside my office network.
>
>
>
> Mask and IPgate seems correct.
>
>
>
> Is anybody has an idea about my trouble?
>
>
>
> Thanks for the help
>
> Best regards
>
> Gilles
>
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

From forum: MicroControllers - Ethernut

Re: [TECH] Questions about water jets

2009-11-12T12:23:53Z

On Thu, 12 Nov 2009 12:49:30 -0700, "YES NOPE9" <yes@...> said:
> #1 What pressure range do they operate at ?

40,000 to 90,000 psi

> #2 Does the water stream contain abrasives ?

Yes, the water is mainly a carrier and for cooling.

> #3 What kind of material is used for the nozzle ?

Sintered boride.

Cheerful regards,

Bob

--
http://www.fastmail.fm - mmm... Fastmail...

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: [TECH] Questions about water jets

2009-11-12T12:17:08Z

YES NOPE9 wrote:
> #1 What pressure range do they operate at ?
> #2 Does the water stream contain abrasives ?
> #3 What kind of material is used for the nozzle ?

Sorry, we're not running a contest currently for the worst formed or most
ambiguous question.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: [TECH] Questions about water jets

2009-11-12T12:16:59Z

> #1 What pressure range do they operate at ?
> #2 Does the water stream contain abrasives ?
> #3 What kind of material is used for the nozzle ?
1. Gargoyle knows.
2. Gargoyle knows.
3. Gargoyle knows.

>From fading memory.
Thousands of psi (insert own unit conversion here).
Almost invariaby - carborundum / saphire often.
?Saphire? (???)(Gargoyle knows).

Russell

2009/11/13 YES NOPE9 <yes@...>

> #1 What pressure range do they operate at ?
> #2 Does the water stream contain abrasives ?
> #3 What kind of material is used for the nozzle ?
>
> Regards
> Gus
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Re: Windows 7 as NFS server

2009-11-12T12:04:34Z

colinux? vmware running a linux host? something like that?

On Thu, Nov 12, 2009 at 8:46 PM, solarwind <x.solarwind.x@...> wrote:
> Hey all, does anyone know of free NFS software for windows 7?
>
> -- [ solarwind ] -- http://solar-blogg.blogspot.com/
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: Micro 7-Segment LCD Glass?

2009-11-12T11:56:29Z

Hi:

Yes that explains the 22 lines. The tens of hours "1" is at the very left edge
of the glass, i.e. there's no room for more segments. So the glass is limited
to a 12 hour time display, it's not a four digit 7-segment display explaining
the 22 drive lines.
http://www.prc68.com/I/DollarWatch.shtml#Fig1

--
Have Fun,

Brooke Clarke
http://www.prc68.com

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [EE]

[TECH] Questions about water jets

2009-11-12T11:49:30Z

#1 What pressure range do they operate at ?
#2 Does the water stream contain abrasives ?
#3 What kind of material is used for the nozzle ?

Regards
Gus
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: MicroControllers - PIC

Windows 7 as NFS server

2009-11-12T11:46:15Z

Hey all, does anyone know of free NFS software for windows 7?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: Maybe obvious ...

2009-11-12T11:20:10Z

Hey Paolo,

2009/11/12 Paolo Simoncelli <simonp@...>

> This should be quite a silly question, but maybe someone knows ;-)
>
> Does task switching start only after a NutThreadCreate() or does some
> context switching run in the background even if just a "hello world"
> main task is running ?

> In other words is NutOs truly "monotask" if no thread is activated ?
>

When the main function is called it is in the thread called "main", which is
the second thread that is run.
The first thread that is run is the idle thread, which does some work, calls
NutThreadCreate to create
the main thread, and mostly just loops on some code that puts the processor
in low power mode over
and over. In Nut the Idle thread must always be ready to run.

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.

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

From forum: MicroControllers - Ethernut

Maybe obvious ...

2009-11-12T10:28:40Z

Hi all,
This should be quite a silly question, but maybe someone knows ;-)

Does task switching start only after a NutThreadCreate() or does some
context switching run in the background even if just a "hello world"
main task is running ?

In other words is NutOs truly "monotask" if no thread is activated ?

Thanks in advance ... 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:
Vuoi condividere con i tuoi collaboratori rubrica e agenda della tua casella di posta?
* Email.it Ha la casella che soddisfa questi requisiti. Per maggiori informazioni chiamaci allo 0125/628650 oppure clicca qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=9585&d=12-11
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

From forum: MicroControllers - Ethernut

Re: Suggested modification to nut\net\tcpsm.c again

2009-11-12T09:25:29Z

On Thu, Nov 12, 2009 at 11:41 AM, Harald Kipp <harald.kipp@...> wrote:

> > Best thing would be to use uint_fast16_t, I think.
>
> That will optimize 32-bit code. But it scares *me* to mix up fixes with
> optimizations. As explained to Zack, I don't see any other advantage.
>
> Let's do the fix first and then think about optimizations.

Yeah. I just threw that in there because Zack asked why it was 16 bit.

> There is plenty of room here in the TCP stack. In fact I discovered the
> problem
> while trying to do some performance tests.
>

It certainly would be nice if the stack were a little bit smarter, but it's
so complicated.

>
>
> > that someone will forget to |= 1 it.
>
> May a comment line help?

Maybe. And I'm sure that if anyone sends you TCP patches the usage of this
variable
is probably one of the first things you look for so bad code getting into
official Nut isn't
that likely.

> Or is there a better solution which doesn't require additional RAM space?
>

I don't know. I've been thinking about this particular code a lot, and I
think that the easiest
to understand thing would be to use one of the free bit in so_tx_flags for
the same purpose
as setting so_rtto to 0.

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

From forum: MicroControllers - Ethernut

Re: _fdopen failed to create the stream on the socket

2009-11-12T08:55:27Z

Ma-Prokop, Yuhong wrote:

> Nut/Os Version: 4.4.0
> Target CPU: Ethernut 3.0E
> File System: UROM

Many bugfixes had been done since. Though, as far as I can remember
right now, none of them is related. I'll give it a try here.

> One more question related to my problem: if the browser closes the website DURING the webserver processing of "NutHttpProcessRequest(http_stream)", shall the stream be closed or the stream shall stay there? I have the feeling that the streams stay there and lead to memory leak.

After NutHttpProcessRequest() exits, both, the socket and the associated
stream needs to be closed. No matter whether to request had been fully
processed or the browser broke the connection.

NutHttpProcessRequest(stream);
fclose(stream);
NutTcpCloseSocket(sock);

Note, that the socket will stay alive in the background for a short time
in order to consume late packets. However, after a few seconds the free
heap space should return to its idle value. More or less, depending on
other applications.

No intention to upgrade to a later version? Specifically we added some
goodies for heap debugging:

http://lists.egnite.de/pipermail/en-nut-discussion/2009-April/010751.html

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

From forum: MicroControllers - Ethernut

Re: Suggested modification to nut\net\tcpsm.c again

2009-11-12T08:41:31Z

Nathan Moore wrote:

> Best thing would be to use uint_fast16_t, I think.

That will optimize 32-bit code. But it scares *me* to mix up fixes with
optimizations. As explained to Zack, I don't see any other advantage.

Let's do the fix first and then think about optimizations. There is
plenty of room here in the TCP stack. In fact I discovered the problem
while trying to do some performance tests.

> Using this timeout value as a flag as well as a timing value still scares
> me, though,
> because everytime it is used or a place that uses it is changed there is a
> chance
> that someone will forget to |= 1 it.

May a comment line help? Or is there a better solution which doesn't
require additional RAM space?

Harald

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

From forum: MicroControllers - Ethernut

Re: Suggested modification to nut\net\tcpsm.c again

2009-11-12T08:35:05Z

Hi Zack,

Nice to have the author of the first patch available.

ennut@... wrote:
> I have heartache casting the 32 bit result from NutGetMillis() to uint16_t.
> Doesn't it make more sense to define so_retran_time as u_long
> rather than u_short in sock_var.h ?

IMHO, that wouldn't make much difference, except better code for 32-bit
and slower as well as larger code for 8-bit targets.

We won't see retransmission timeouts above 65 seconds. On the contrary I
initially intended to limit its value to a few seconds, before I located
the real problem.

The NutGetMillis() overflow will happen anyway, no matter how many bits
we'll use.

> I didn't look at the code but

As I said, the first patch was contributed by *you*. ;-)

Harald

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

From forum: MicroControllers - Ethernut

Re: Cute little oscilloscope

2009-11-12T08:26:07Z

At 03:13 AM 11/12/2009, Wouter van Ooijen wrote:
>Bob Blick wrote:
> > This is where scopes are heading:
> >
> >
> http://www.seeedstudio.com/depot/micro-digital-storage-oscilloscopedso-nano-p-512.html
>
>That looks like a nice platform for embedded development. A pity they
>show "-1" in stock :(

That might have been me trying to order it last week - I saw the Nano
when I was placing my order for a couple of Bus Pirates.

Seeed Studio has some neat stuff!

dwayne

--
Dwayne Reid <dwayner@...>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax
www.trinity-electronics.com
Custom Electronics Design and Manufacturing

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: Power Supply Health Question

2009-11-12T07:11:05Z

Bingo problem solved!

Having another look around I noticed that I had jumpered the 5V-GND lines
with a resistor to provide min. load for voltage regulation. I had
forgotten about that and didn't see it in my initial look. The resistor had
come loose and was no longer making contact.

The unit is much smaller than a PC power supply but the idea is the same.

Thanks for all the suggestions.

Gordon Williams

----- Original Message -----
From: "M.L." <m@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Monday, November 09, 2009 9:25 PM
Subject: Re: [EE] Power Supply Health Question

> On Mon, Nov 9, 2009 at 8:48 PM, Gordon Williams <gwilliams@...> wrote:
> > Hi,
> >
> > I've got a 120V switching power supply that produces 12 and 5 Vdc
outputs
> > that I've been using for the last couple of years to power a digital
piano
> > after the original quit. It is salvaged out of an old piece of equipment
> > somewhere. The 12 V goes to the piano and the 5V goes to an LED to tell
me
> > the main power supply is on. It stays on all the time and the piano has
> > it's own power switch.
> >
> > I noticed the other day that the LED was pulsing and the supply was
making a
> > clicking sound at the same time of the pulses, at about 3 Hz. The 12 V
> > supply output was fluctuating wildly with no load. When I loaded the
supply
> > with 200 mA current everything settled down with 11.5 V output and the
LED
> > stopped pulsing. I don't remember that the supply was doing this
pulsating
> > under no-load originally when I started using it 2-3 years ago. It's got
me

> > concerned that something is not working right.
> >
> > Could this be a sign that the power supply is starting to break down? Is
> > the clicking sound from the transformer?
> >
> > Suggestions?
> >
> > Gordon Williams
> >
>
> Some old switching power supplies needed a minimum load current in
> order to regulate. Your supply might have a power resistor that has
> burned out from being continuously on and running at 100C for 2-3
> years, or you might have bad electrolytic caps, both, or neither.
>
>
> --
> Martin K.
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [EE]

Re: Suggested modification to nut\net\tcpsm.c again

2009-11-12T07:08:44Z

On Thu, Nov 12, 2009 at 7:39 AM, <ennut@...> wrote:

> I have heartache casting the 32 bit result from NutGetMillis() to
> uint16_t.
> Doesn't it make more sense to define so_retran_time as u_long
> rather than u_short in sock_var.h ?
>

I suspect that this is done for AVR because RAM is more limited and doing
math
on a 32 bit value requires about twice the number of machine instructions as
on
a 16 bit value.
Best thing would be to use uint_fast16_t, I think.

Using this timeout value as a flag as well as a timing value still scares
me, though,
because everytime it is used or a place that uses it is changed there is a
chance
that someone will forget to |= 1 it.

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

From forum: MicroControllers - Ethernut

Re: _fdopen failed to create the stream on the socket

2009-11-12T05:03:53Z

Hello Harald,

thanks for your answer!

What I have is as following:

Nut/Os Version: 4.4.0
Target CPU: Ethernut 3.0E
File System: UROM

I have 7 server threads running at a time.

I firstly thought it is because the "_iob[]" which is used in "_fdopen" is not protected by multiple thread accesses, then i added a MUX for the "_iob[]", but the result is same.

Then I found out that the function "_close(int)" which is called in "fclose()" failed, this leads to the failing in "fclose()"

One more question related to my problem: if the browser closes the website DURING the webserver processing of "NutHttpProcessRequest(http_stream)", shall the stream be closed or the stream shall stay there? I have the feeling that the streams stay there and lead to memory leak.

Best Regards,
Hong

-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-bounces@... [mailto:en-nut-discussion-bounces@...] Im Auftrag von en-nut-discussion-request@...
Gesendet: Donnerstag, 12. November 2009 12:00
An: en-nut-discussion@...
Betreff: En-Nut-Discussion Digest, Vol 73, Issue 11

Send En-Nut-Discussion mailing list submissions to
en-nut-discussion@...

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
or, via email, send a message with subject or body 'help' to
en-nut-discussion-request@...

You can reach the person managing the list at
en-nut-discussion-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of En-Nut-Discussion digest..."

Today's Topics:

1. _fdopen failed to create the stream on the socket
(Ma-Prokop, Yuhong)
2. Re: _fdopen failed to create the stream on the socket
(Harald Kipp)
3. Re: Timing issues on Ethernut 1.3 (AVR) (Harald Kipp)
4. Re: Timing issues on Ethernut 1.3 (AVR) (Harald Kipp)
5. Suggested modification to nut\net\tcpsm.c again (Harald Kipp)
6. FTP server fails with very small files (Malte Marwedel)

----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Nov 2009 09:17:36 +0100
From: "Ma-Prokop, Yuhong" <yuhong.ma.prokop@...>
Subject: [En-Nut-Discussion] _fdopen failed to create the stream on
the socket
To: <en-nut-discussion@...>
Message-ID:
<02CDDA1E92DA1C4BB91B40FB0555A9B30145E716@...>
Content-Type: text/plain; charset="us-ascii"

Hello Everyone,

I have one problem with my nut/os Webserver: after some calling from the
clients (browers) the webserver does not response any more!

I tried to track along the problem: it is because the _fdopen function
failed to create stream on the socket and returns "-1". According to my
debugging output the opened stream number is over the FOPEN_MAX which is
defined in nut/os.

But fclose function was called everytime after the successful _fdopen.
Then i found out that the fclose (as following) returns sometimes "255"
instead of "0" as it should be, so the existing stream cannot be closed,
then until the maximal streams are opened, no further clients-request
shall be processed!

Does somebody have the same problem with nut/os webserver?

Any help is appreciated!

Hong

my webserver thread is as following:

THREAD(Service, arg) {

FILE *http_stream;

TCPSOCKET *sock;

u_char id = (u_char) ((uptr_t) arg);

// give each thread a (unique) priority

NutThreadSetPriority( EHZ_HTTP_PRIO ); //+ id

/*

* Now loop endless for connections.

*/

for(;;)

{

/*

* Create a socket.

*

* May fail because of lacking ressources

*/

if ((sock = NutTcpCreateSocket()) == 0)

{

LOG_ERROR("%d: tcp socket create failed", id);

NutSleep(5000);

continue;

}

else

/*

* Set socket options.

*/

{

u_short mss = 1460;

u_short tcpbufsiz = 8760;

u_long tmo = 5000;

if (NutTcpSetSockOpt(sock, TCP_MAXSEG, &mss, sizeof(mss)))

LOG_ERROR("Sockopt MSS failed");

if (NutTcpSetSockOpt(sock, SO_RCVBUF, &tcpbufsiz,
sizeof(tcpbufsiz)))

LOG_ERROR("Sockopt rxbuf failed");

if (NutTcpSetSockOpt(sock, SO_RCVTIMEO, &tmo, sizeof(tmo)))

LOG_ERROR("Sockopt rx timeout failed");

}

/*

* Listen on port 80. This call will block until we get a
connection

* from a client.

*/

NutTcpAccept(sock, 80);

// printf("remote-ip: %s\r\n", inet_ntoa(sock->so_remote_addr));

/*

* Wait until at least 4 kByte of free RAM is available. This
will

* keep the client connected in low memory situations.

*/

while( NutHeapAvailable() < 4096 )

{

LOG_ERROR("%d: not enough memory!", id );

// reboot the device if the amount of memory is too
small

//****

RESET;

//****

NutSleep(1000);

}

/*

* Associate a stream with the socket so we can use standard I/O
calls.

*

* should not fail

*/

// inserting a timeout here was a tip of Piotr Szlachta in the
ethernut mailing list:

//
http://lists.egnite.de/pipermail/en-nut-discussion/2007-November/008655.
html

int timeout=0;

while ( !(http_stream = _fdopen((int) ((uptr_t) sock), "r+b"))
&& ++timeout<0xFF )

NutSleep (10);

if ((int)http_stream != 0 && (int) http_stream != -1 &&
(int)http_stream != -2) {

/*

* This API call saves us a lot of work. It will parse the

* client's HTTP request, send any requested file from the

* registered file system or handle CGI requests by calling

* our registered CGI routine.

*/

#ifndef USE_UROM_FOR_HTTP

if(!isMmcAccessGranted()) {

LOG_ERROR("Please check SD-Card.");

}

else {

NutHttpProcessRequest(http_stream);

}

#else

NutHttpProcessRequest(http_stream);

#endif

/*

* Destroy the virtual stream device.

*/

fclose_result = fclose(http_stream);

LOG_ERROR("INFO: fclose with stream: %d result: %d: \n",
http_stream, fclose_result);

}

else {

LOG_ERROR("DEFEKT with Thread %d: fdopen result: %d: \n",id,
(int)http_stream);

NutSleep(100);

}

/*

* Close our socket.

*/

if( (NutTcpCloseSocket(sock)) == -1)

LOG_ERROR("ACHTUNG: Socket not closed");

}

}

The _fdopen function in my nut/os:

(I modified the function just lightly to get know the failed reason)

FILE *_fdopen(int fd, CONST char *mode)

{

int mflags = _O_TEXT;

u_char i;

/*

* Translate file mode.

*/

if ((mflags = _fmode(mode)) == EOF)

return (FILE*)0;

/*

* Find an empty slot.

*/

for (i = 3; __iob[i]; i++)

if (i >= FOPEN_MAX - 1) {

errno = ENFILE;

// return 0;

return (FILE*)(-1);

}

if ((__iob[i] = malloc(sizeof(FILE))) != 0) {

__iob[i]->iob_fd = fd;

__iob[i]->iob_mode = mflags;

__iob[i]->iob_flags = 0;

__iob[i]->iob_unget = 0;

return __iob[i];

} else

{

errno = ENOMEM;

return (FILE*)(-2);

}

// return __iob[i];

}

The _fdopen function in my nut/os:

int fclose(FILE * stream)

{

int rc = EOF;

u_char i;

/*

* Search the list first to detect bad stream pointer.

*/

if (stream == 0) {

errno = EBADF;

return EOF;

}

for (i = 0; __iob[i] != stream;) {

if (++i >= FOPEN_MAX) {

errno = EBADF;

return EOF;

}

}

/*

* Ignore unopened standard streams.

*/

//if ((void *) stream < RAMSTART)

// return 0;

/*

* Close the file or device.

*/

if (_close(stream->iob_fd) == 0)

rc = 0;

free(stream);

__iob[i] = 0;

return rc;

}

------------------------------

Message: 2
Date: Thu, 12 Nov 2009 09:17:32 +0100
From: Harald Kipp <harald.kipp@...>
Subject: Re: [En-Nut-Discussion] _fdopen failed to create the stream
on the socket
To: "Ethernut User Chat (English)" <en-nut-discussion@...>
Message-ID: <4AFBC49C.8010606@...>
Content-Type: text/plain; charset=ISO-8859-1

Ma-Prokop, Yuhong wrote:

> But fclose function was called everytime after the successful _fdopen.
> Then i found out that the fclose (as following) returns sometimes "255"
> instead of "0" as it should be, so the existing stream cannot be closed,
> then until the maximal streams are opened, no further clients-request
> shall be processed!

Hong,

can you please provide some more information.

1. Nut/OS version
2. Target CPU
3. File system

> Does somebody have the same problem with nut/os webserver?

Our online reference demo at

http://ethernut.microweb.org/

currently has an uptime of > 1 month. It needs to be restarted only to
clear the spam from the guest book. In general it looks quite reliable.

Harald

PS: I recently discovered 2 serious bugs in Nut/OS for 32-bit CPUs. But
the problems are different. More on this later.

------------------------------

Message: 3
Date: Thu, 12 Nov 2009 10:10:44 +0100
From: Harald Kipp <harald.kipp@...>
Subject: Re: [En-Nut-Discussion] Timing issues on Ethernut 1.3 (AVR)
To: "Ethernut User Chat (English)" <en-nut-discussion@...>
Message-ID: <4AFBD114.3070905@...>
Content-Type: text/plain; charset=ISO-8859-1

Hi Daniel,

Daniel wrote:

> Issue 1, NutGetMillis()
> =======================

I tried this one:

#include <dev/board.h>
#include <sys/thread.h>
#include <sys/timer.h>

#include <stdio.h>
#include <io.h>

THREAD(Thread, arg)
{
for (;;) {
uint32_t start = NutGetMillis();
uint32_t end = start + 500;
uint16_t i = 0;

printf("Start Millis %p: %lu ms\n", arg, NutGetMillis());
do {
NutThreadYield();
i++;
if (i > 500) {
printf("Current Millis %p: %lu ms\n", arg, NutGetMillis());
i = 0;
}
} while(NutGetMillis() < end);
printf(" End Millis %p: %lu ms\n", arg, NutGetMillis());
}
}

int main(void)
{
uint32_t baud = 115200;
int i;

NutRegisterDevice(&DEV_DEBUG, 0, 0);
freopen(DEV_DEBUG_NAME, "w", stdout);
_ioctl(_fileno(stdout), UART_SETSPEED, &baud);

puts("\nTest Millis");

for (i = 1; i <= 10; i++) {
NutThreadCreate("th", Thread, (void *)i, 512);
}

for (;;) {
NutSleep(1000);
}
return 0;
}

It works as expected:

Test Millis
Start Millis 0x1: 5 ms
Start Millis 0x2: 7 ms
Start Millis 0x3: 9 ms
Start Millis 0x4: 11 ms
Start Millis 0x5: 13 ms
Start Millis 0x6: 15 ms
Start Millis 0x7: 17 ms
Start Millis 0x8: 20 ms
Start Millis 0x9: 22 ms
Start Millis 0xa: 24 ms
Current Millis 0x1: 109 ms
Current Millis 0x2: 111 ms
Current Millis 0x3: 114 ms
Current Millis 0x4: 116 ms
Current Millis 0x5: 119 ms
Current Millis 0x6: 121 ms
Current Millis 0x7: 124 ms
Current Millis 0x8: 126 ms
Current Millis 0x9: 129 ms
Current Millis 0xa: 131 ms
Current Millis 0x1: 218 ms
Current Millis 0x2: 220 ms
...
End Millis 0x1: 505 ms
Start Millis 0x1: 507 ms
End Millis 0x2: 509 ms
Start Millis 0x2: 511 ms
End Millis 0x3: 514 ms
Start Millis 0x3: 516 ms
End Millis 0x4: 518 ms
Start Millis 0x4: 520 ms
End Millis 0x5: 523 ms
Start Millis 0x5: 525 ms
End Millis 0x6: 527 ms
Start Millis 0x6: 529 ms
End Millis 0x7: 532 ms
Start Millis 0x7: 534 ms
End Millis 0x8: 536 ms
Start Millis 0x8: 539 ms
End Millis 0x9: 541 ms
Start Millis 0x9: 543 ms
End Millis 0xa: 545 ms
Start Millis 0xa: 548 ms
...

May be in your application you should check entry and return time of
NutThreadYield(). Possibly another thread occupies the CPU for too long
time.

Harald

PS: I tested on Ethernut 3 (ARM), but AVR should work similar.

------------------------------

Message: 4
Date: Thu, 12 Nov 2009 10:28:31 +0100
From: Harald Kipp <harald.kipp@...>
Subject: Re: [En-Nut-Discussion] Timing issues on Ethernut 1.3 (AVR)
To: "Ethernut User Chat (English)" <en-nut-discussion@...>
Message-ID: <4AFBD53F.6060904@...>
Content-Type: text/plain; charset=ISO-8859-1

Daniel wrote:

> Issue 2, NutGetTickCount()
> ======================

> The only hint i have is that I'm using the _delay_us(x) function, which is
> not from Ethernut. Maybe there`s the problem?

Could be. In my previous example I used DEV_DEBUG, a polling driver,
which will never release the CPU. Thus, each thread is blocked until the
running thread calls NutThreadYield(). The same is true for _delay_us(x).

As long as you are working with resolutions of milliseconds, you should
use Nut/OS events and timers, because they will release the CPU.

If you need higher resolutions, you may use a native timer interrupts
for polling, if possible. If the interrupt routine detects a change, it
calls NutEventPostFromIrq() to wake up a thread. In your example the
status change will be detected by the timer interrupt routine and the
thread will wait for a change in NutEventWait(). The optimal solution
is, of course, if the status change can be detected by a dedicated
interrupt, avoiding timer interrupt polling.

Keep in mind: As long as nothing happens, good application will run the
idle thread. Polling is bad for cooperative systems like Nut/OS.

Harald

------------------------------

Message: 5
Date: Thu, 12 Nov 2009 10:54:00 +0100
From: Harald Kipp <harald.kipp@...>
Subject: [En-Nut-Discussion] Suggested modification to nut\net\tcpsm.c
again
To: "Ethernut User Chat (English)" <en-nut-discussion@...>
Message-ID: <4AFBDB38.3030300@...>
Content-Type: text/plain; charset=ISO-8859-15

Some time ago Zack suggested a modification of the TCP state machine:

http://lists.egnite.de/pipermail/en-nut-discussion/2007-May/008089.html

I assume, that this one fixed the problem at that time. However, recent
tests showed, that the problem is back again.

I do not have a proof, just a strong feeling that somehow the way
changed, the GNU compiler does calculations. Wasn't there similar fix
required during the last months? I'm currently using GCC 4.4.2.

Unfortunately the problem now appears more often after

http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/net/tcpout.c?r1=1751&r2=2082

because so_retran_time may be 1 ms ahead.

As a result, Ethernut sends duplicate segments quite often.

Anyone else observed something similar with GCC calculation routines?

The following change seems to fix it.

/*
* Process retransmit timer.
*/
if (sock->so_tx_nbq && sock->so_retran_time) {
uint16_t millis = (uint16_t)NutGetMillis();
uint16_t diff = millis > sock->so_retran_time ? millis -
sock->so_retran_time : sock->so_retran_time - millis;
if (diff >= sock->so_rtto) {
NutTcpStateRetranTimeout(sock);
}
}

I'm afraid, that there are other parts of the OS/Net code failing with
the latest GCC.

Harald

------------------------------

Message: 6
Date: Thu, 12 Nov 2009 11:54:38 +0100
From: Malte Marwedel <m.marwedel@...>
Subject: [En-Nut-Discussion] FTP server fails with very small files
To: "Ethernut User Chat (English)" <en-nut-discussion@...>
Message-ID: <4AFBE96E.3000006@...>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hello,
I observed, that putting very small files (less than 54 bytes in size)
to a board with Nut/OS results in a "550 Failed" with the ftp server.

I tried to find the cause of the problem and discovered that
NutFtpDataConnect retuns 0 because the NutTcpConnect call returns -1.
I further observed that the error goes away as soon as I placed some
debug outputs before the NutFtpDataConnect call. So, for me it looks
like a timing issue. Can someone verify this problem?
My system is: Arthernet board with Nut/OS 4.8.0 using gcc 4.3.2

Malte

------------------------------

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

End of En-Nut-Discussion Digest, Vol 73, Issue 11
*************************************************
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

From forum: MicroControllers - Ethernut

Re: Suggested modification to nut\net\tcpsm.c again

2009-11-12T04:39:58Z

I have heartache casting the 32 bit result from NutGetMillis() to uint16_t.
Doesn't it make more sense to define so_retran_time as u_long
rather than u_short in sock_var.h ?

I didn't look at the code but I would check to see if the u_long
result from NutGetMillis() is
stored in so_time_wait. If so I would change it to u_long.

Thoughts?

Zack

At 04:54 AM 11/12/2009, you wrote:

>Some time ago Zack suggested a modification of the TCP state machine:
>
>http://lists.egnite.de/pipermail/en-nut-discussion/2007-May/008089.html
>
>I assume, that this one fixed the problem at that time. However, recent
>tests showed, that the problem is back again.
>
>I do not have a proof, just a strong feeling that somehow the way
>changed, the GNU compiler does calculations. Wasn't there similar fix
>required during the last months? I'm currently using GCC 4.4.2.
>
>Unfortunately the problem now appears more often after
>
>http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/net/tcpout.c?r1=1751&r2=2082
>
>because so_retran_time may be 1 ms ahead.
>
>As a result, Ethernut sends duplicate segments quite often.
>
>Anyone else observed something similar with GCC calculation routines?
>
>The following change seems to fix it.
>
>/*
> * Process retransmit timer.
> */
>if (sock->so_tx_nbq && sock->so_retran_time) {
> uint16_t millis = (uint16_t)NutGetMillis();
> uint16_t diff = millis > sock->so_retran_time ? millis -
>sock->so_retran_time : sock->so_retran_time - millis;
> if (diff >= sock->so_rtto) {
> NutTcpStateRetranTimeout(sock);
> }
>}
>
>I'm afraid, that there are other parts of the OS/Net code failing with
>the latest GCC.
>
>Harald
>
>
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion

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

From forum: MicroControllers - Ethernut

Re: Cute little oscilloscope

2009-11-12T02:59:52Z

On Thu, Nov 12, 2009 at 7:14 AM, SM Ling <ipal11@...> wrote:
> The nano is actually an open source product, but information is in
> Chinese, and the firmware can be customised.

Is the doc in electronic format? If yes, is Google translation makes
any sense if you try to get it translated to English?

Thanks
Tamas
--
/* www.mcuhobby.com */ int main() { char *a,*s,*q; printf(s="/*
www.mcuhobby.com */ int main() { char *a,*s,*q; printf(s=%s%s%s,
q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

FTP server fails with very small files

2009-11-12T02:54:38Z

Hello,
I observed, that putting very small files (less than 54 bytes in size)
to a board with Nut/OS results in a "550 Failed" with the ftp server.

I tried to find the cause of the problem and discovered that
NutFtpDataConnect retuns 0 because the NutTcpConnect call returns -1.
I further observed that the error goes away as soon as I placed some
debug outputs before the NutFtpDataConnect call. So, for me it looks
like a timing issue. Can someone verify this problem?
My system is: Arthernet board with Nut/OS 4.8.0 using gcc 4.3.2

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

From forum: MicroControllers - Ethernut

Thursday's New Giveaways! (Nov 12)

2009-11-12T02:52:16Z

Hello Everyone!

Here is a FRESH selection of stuff members can collect for nothing

There is lots to grab in this new Giveaway Mix!

http://groups.google.com/group/freebieshare/web/giveaway-mix-november-12

Enjoy!

From forum: OOPic

Re: Cute little oscilloscope

2009-11-12T02:51:32Z

> How is the 5M scope? Build quality and performance in it's class would like to hear your reviews. Is the scope open source too?

Not open source as far as I know. Have it only for a day, so I am not
qualify to do a review as yet. Check up youtube, there are a few
video there. Google it, already some reviews on it.

Quick point:
1. The build is good (bought the assembled set). But I hope it is
not like those 1 month life-time product. There was no such
complaints on the net yet.
2. The various buttons and switches make operation it easy and fast.
To me, this is important as compare to navigating around the on screen
menu when I am using the tool.
3. It is smaller and lighter than it appears to be. About size of 2
pieces 2.5" external HD stack together.
4. Works off 2x18650 lithium battery. Yet to test out the battery life.
5. Basic, useable, and it has 1-shot mode
6. No case. Can't save to SD.

If you can wait for several more months, the chance of another open
source handheld scope (much higher sampling rate) materializing is
quite high. You may get it through taobao, but paying is a big
problem though.

Ling SM
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: Cute little oscilloscope

2009-11-12T02:13:57Z

Bob Blick wrote:
> This is where scopes are heading:
>
> http://www.seeedstudio.com/depot/micro-digital-storage-oscilloscopedso-nano-p-512.html

That looks like a nice platform for embedded development. A pity they
show "-1" in stock :(

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Suggested modification to nut\net\tcpsm.c again

2009-11-12T01:54:00Z

Some time ago Zack suggested a modification of the TCP state machine:

http://lists.egnite.de/pipermail/en-nut-discussion/2007-May/008089.html

I assume, that this one fixed the problem at that time. However, recent
tests showed, that the problem is back again.

I do not have a proof, just a strong feeling that somehow the way
changed, the GNU compiler does calculations. Wasn't there similar fix
required during the last months? I'm currently using GCC 4.4.2.

Unfortunately the problem now appears more often after

http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/net/tcpout.c?r1=1751&r2=2082

because so_retran_time may be 1 ms ahead.

As a result, Ethernut sends duplicate segments quite often.

Anyone else observed something similar with GCC calculation routines?

The following change seems to fix it.

/*
* Process retransmit timer.
*/
if (sock->so_tx_nbq && sock->so_retran_time) {
uint16_t millis = (uint16_t)NutGetMillis();
uint16_t diff = millis > sock->so_retran_time ? millis -
sock->so_retran_time : sock->so_retran_time - millis;
if (diff >= sock->so_rtto) {
NutTcpStateRetranTimeout(sock);
}
}

I'm afraid, that there are other parts of the OS/Net code failing with
the latest GCC.

Harald

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

From forum: MicroControllers - Ethernut

Re: Timing issues on Ethernut 1.3 (AVR)

2009-11-12T01:28:31Z

Daniel wrote:

> Issue 2, NutGetTickCount()
> ======================

> The only hint i have is that I'm using the _delay_us(x) function, which is
> not from Ethernut. Maybe there`s the problem?

Could be. In my previous example I used DEV_DEBUG, a polling driver,
which will never release the CPU. Thus, each thread is blocked until the
running thread calls NutThreadYield(). The same is true for _delay_us(x).

As long as you are working with resolutions of milliseconds, you should
use Nut/OS events and timers, because they will release the CPU.

If you need higher resolutions, you may use a native timer interrupts
for polling, if possible. If the interrupt routine detects a change, it
calls NutEventPostFromIrq() to wake up a thread. In your example the
status change will be detected by the timer interrupt routine and the
thread will wait for a change in NutEventWait(). The optimal solution
is, of course, if the status change can be detected by a dedicated
interrupt, avoiding timer interrupt polling.

Keep in mind: As long as nothing happens, good application will run the
idle thread. Polling is bad for cooperative systems like Nut/OS.

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

From forum: MicroControllers - Ethernut

Re: Cute little oscilloscope

2009-11-12T01:26:17Z

>The nano is actually an open source product, but information is in
>Chinese, and the firmware can be customised. Battery life was one of
>the reasons, the designer settled for 1MHz. It was targeting at lift
>and car repairmen.

Do you have any link of the Nano Scope open source?

Octavio Nogueira
Tato Equipamentos Eletrônicos Ltda
Tel (11) 5506-5335

2009/11/12 SM Ling <ipal11@...>

> After resisting for a month, I bought the 5M jyetech scope. It
> arrived yesterday :-)
>
> The nano is actually an open source product, but information is in
> Chinese, and the firmware can be customised. Battery life was one of
> the reasons, the designer settled for 1MHz. It was targeting at lift
> and car repairmen.
>
> There is a somewhat similar ee-forum in China like piclist, and they
> are pumping out kits and stuff like nano-scope quite frequently, some
> pick up be seedstudio.
>
> Cheers, Ling SM
>
> On Thu, Nov 12, 2009 at 2:23 PM, M. Adam Davis <stienman@...> wrote:
> > That one is only good to 1MHz though. Good for slow clocks and analog
> work.
> >
> > I'm actually thinking that we'll go towards iPhone/android DSOs for
> > field work, but the reality is that there's not much replacement for a
> > large clear display with a good set of controls for bench work.
> >
> > On Thu, Nov 12, 2009 at 12:45 AM, Bob Blick <bobblick@...> wrote:
> >> This is where scopes are heading:
> >>
> >>
> http://www.seeedstudio.com/depot/micro-digital-storage-oscilloscopedso-nano-p-512.html
> >>
> >> I'm sure the analog stage is crap, but stuff like this is sure to push
> >> some of the quality test equipment makers to do pocket-sized gear.
> >>
> >> -Bob
> >> --
> >> http://www.piclist.com PIC/SX FAQ & list archive
> >> View/change your membership options at
> >> http://mailman.mit.edu/mailman/listinfo/piclist
> >>
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

From forum: PIC - [OT]

Re: Timing issues on Ethernut 1.3 (AVR)

2009-11-12T01:10:44Z

Hi Daniel,

Daniel wrote:

> Issue 1, NutGetMillis()
> =======================

I tried this one:

#include <dev/board.h>
#include <sys/thread.h>
#include <sys/timer.h>

#include <stdio.h>
#include <io.h>

THREAD(Thread, arg)
{
for (;;) {
uint32_t start = NutGetMillis();
uint32_t end = start + 500;
uint16_t i = 0;

printf("Start Millis %p: %lu ms\n", arg, NutGetMillis());
do {
NutThreadYield();
i++;
if (i > 500) {
printf("Current Millis %p: %lu ms\n", arg, NutGetMillis());
i = 0;
}
} while(NutGetMillis() < end);
printf(" End Millis %p: %lu ms\n", arg, NutGetMillis());
}
}

int main(void)
{
uint32_t baud = 115200;
int i;

NutRegisterDevice(&DEV_DEBUG, 0, 0);
freopen(DEV_DEBUG_NAME, "w", stdout);
_ioctl(_fileno(stdout), UART_SETSPEED, &baud);

puts("\nTest Millis");

for (i = 1; i <= 10; i++) {
NutThreadCreate("th", Thread, (void *)i, 512);
}

for (;;) {
NutSleep(1000);
}
return 0;
}

It works as expected:

Test Millis
Start Millis 0x1: 5 ms
Start Millis 0x2: 7 ms
Start Millis 0x3: 9 ms
Start Millis 0x4: 11 ms
Start Millis 0x5: 13 ms
Start Millis 0x6: 15 ms
Start Millis 0x7: 17 ms
Start Millis 0x8: 20 ms
Start Millis 0x9: 22 ms
Start Millis 0xa: 24 ms
Current Millis 0x1: 109 ms
Current Millis 0x2: 111 ms
Current Millis 0x3: 114 ms
Current Millis 0x4: 116 ms
Current Millis 0x5: 119 ms
Current Millis 0x6: 121 ms
Current Millis 0x7: 124 ms
Current Millis 0x8: 126 ms
Current Millis 0x9: 129 ms
Current Millis 0xa: 131 ms
Current Millis 0x1: 218 ms
Current Millis 0x2: 220 ms
...
End Millis 0x1: 505 ms
Start Millis 0x1: 507 ms
End Millis 0x2: 509 ms
Start Millis 0x2: 511 ms
End Millis 0x3: 514 ms
Start Millis 0x3: 516 ms
End Millis 0x4: 518 ms
Start Millis 0x4: 520 ms
End Millis 0x5: 523 ms
Start Millis 0x5: 525 ms
End Millis 0x6: 527 ms
Start Millis 0x6: 529 ms
End Millis 0x7: 532 ms
Start Millis 0x7: 534 ms
End Millis 0x8: 536 ms
Start Millis 0x8: 539 ms
End Millis 0x9: 541 ms
Start Millis 0x9: 543 ms
End Millis 0xa: 545 ms
Start Millis 0xa: 548 ms
...

May be in your application you should check entry and return time of
NutThreadYield(). Possibly another thread occupies the CPU for too long
time.

Harald

PS: I tested on Ethernut 3 (ARM), but AVR should work similar.

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

From forum: MicroControllers - Ethernut