Action points/ TODO lists?

[Jesper]

Hi!

I guess its about time too to discuss a general TODO list or a action
point list?

For example, one point (as mentioned before) is to make is to rewrite
the current clock-arch.c remaking it to work with 8bit timers instead
of 16. (and in my opinion also rewriting the timer to utilize clock
instead of using a second timer. This way only one 8bit timer is
necessary in hardware (leaving all other hw timers to be used freely).

Anyways, how do we create a collective todo-list? Is it perhaps best
to make a sticky thread with one designated moderator to edit first
post with status and assignment for each todo point?

And I guess some discussions should be made for each todo-point too?

I guess the google-guru can best answer this?

And also perhaps we should all make are own branches and then merge
them all in a couple of weeks or so? That way we dont have to be
worried about all of us interfering with eachothers work..

[Jonas Finnemann Jensen]

Hi,

I think a todo list would be a good idea to manage things... But maybe we should consider using the issue tracker on google code... Then we'd be able to discuss each issue, assign them... Rate their importance... and target them for milestones...
The issue tracker is found here:
http://code.google.com/p/avr-uip/issues/list
We can set it up to send a mail to the mailinglist every time an issue changes...

I don't know about branches, it might be a good idea... since we won't all be developing on the same hardware... Then we can just port in the things that are good to the main tree....

--
Regards Jonas Finnemann Jensen.

[Jesper]

I thought the issue list was explicitly for known bugs. And in my
experience we should probably keep that part seperate from the
milestones / todo-list.

I guess that is a matter of preferance, but as I said.. My opinion is
that we should keep the bugtracking seperate from milestones...

What do you guys think?

/Jesper

On 28 Apr, 09:32, "Jonas Finnemann Jensen" <jop...@gmail.com> wrote:
> Hi,
>
> I think a todo list would be a good idea to manage things... But maybe we
> should consider using the issue tracker on google code... Then we'd be able
> to discuss each issue, assign them... Rate their importance... and target
> them for milestones...
> The issue tracker is found here:http://code.google.com/p/avr-uip/issues/list
> We can set it up to send a mail to the mailinglist every time an issue
> changes...
>
> I don't know about branches, it might be a good idea... since we won't all
> be developing on the same hardware... Then we can just port in the things
> that are good to the main tree....
>
> --
> Regards Jonas Finnemann Jensen.
>

[Jonas Finnemann Jensen]

I thought the issue list was explicitly for known bugs. And in my
experience we should probably keep that part seperate from the
milestones / todo-list.

Well, that's one way to view it... But it should be possible to create a custom label for the todo-list in the issue tracker...
However, I wouldn't mind working with a plain text file or similar... As long as we can keep a  discussion associated with the list...

Perhaps a roadmap entry in the wiki would do?

--
Regards Jonas Finnemann Jensen.

[Jesper]

A roadmap sounds perfect to me... That should provide a perfect way
for all members to add/edit entries.. And maintain an open discussion
about entries..
And still keep bugtracking seperate..

However that is just my opinion, if you guys prefer to do it
differently that would be fine with me..

/Jesper

> > > > worried about all of us interfering with eachothers work..- Dölj citerad text -
>
> - Visa citerad text -

[Jonathan / WebCom-Design]

Hi guys, sorry by my delay... I was in bed those last days, sick.
Now Im better. I think that we can go through the roadmap... I think
that any idea is good, just to have a list to follow, also I think that
we should go ahead with our own branches, then make one final release
with the port for each hardware we used... then we use that release to
continue working over the todo list.

I dont know if it will help, but I have a Mantis installation ready in
one of my servers, http://bugs.webiland.com.ar
If you think that it will help, I can create a new project there and we
could use it to follow a guide. I think it's an excellent bug tracker.

I'm already working over the code, I hope I can finish it asap and
upload it to start seeing what's next.

Happy to see that it's progressing and to be working together!

Cheers,

--
Jonathan Granade
WebCom-Design

[Jonas Finnemann Jensen]

Hi,

I've created a wiki entry for the roadmap:
http://code.google.com/p/avr-uip/wiki/Roadmap

So I think we should start adding things... then we'll discuss them on this list...

I dont know if it will help, but I have a Mantis installation ready in
one of my servers, http://bugs.webiland.com.ar
If you think that it will help, I can create a new project there and we
could use it to follow a guide. I think it's an excellent bug tracker.

There's an issue tracker integrated with google code I think it's okay, but we can replace that if you guys would rather work with something else... But I guess we don't have to make up our mind about that just yet...

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Excellent, I will take a look now

--
Jonathan Granade
WebCom-Design

Jonas Finnemann Jensen wrote:
> Hi,
>
> I've created a wiki entry for the roadmap:
> http://code.google.com/p/avr-uip/wiki/Roadmap
>
> So I think we should start adding things... then we'll discuss them on
> this list...
>
> I dont know if it will help, but I have a Mantis installation ready in
> one of my servers, http://bugs.webiland.com.ar

> <http://bugs.webiland.com.ar/>

> <mailto:jop...@gmail.com>> wrote:
> >
> >>> I thought the issue list was explicitly for known bugs. And in my
> >>> experience we should probably keep that part seperate from the
> >>> milestones / todo-list.
> >>>
> >> Well, that's one way to view it... But it should be possible to
> create a
> >> custom label for the todo-list in the issue tracker...
> >> However, I wouldn't mind working with a plain text file or
> similar... As
> >> long as we can keep a discussion associated with the list...
> >>
> >> Perhaps a roadmap entry in the wiki would do?
> >>
> >> --
> >> Regards Jonas Finnemann Jensen.
> >>
> >>
> >>
> >> On Mon, Apr 28, 2008 at 3:06 PM, Jesper <jdere...@hotmail.com
> <mailto:jdere...@hotmail.com>> wrote:
> >>
> >>
> >>> I thought the issue list was explicitly for known bugs. And in my
> >>> experience we should probably keep that part seperate from the
> >>> milestones / todo-list.
> >>>
> >>> I guess that is a matter of preferance, but as I said.. My
> opinion is
> >>> that we should keep the bugtracking seperate from milestones...
> >>>
> >>> What do you guys think?
> >>>
> >>> /Jesper
> >>>
> >>> On 28 Apr, 09:32, "Jonas Finnemann Jensen" <jop...@gmail.com

[Jesper]

I edited the todo-list and set two bullets under clock part..

bullet 1 (using 8/16 bit timers configurable in header files):
Is it really necessary to have a 16bit timer for the clock? It should
be sufficient with a 8bit timer with all impl.
The only issue here is where system_time overflows, where I guess the
time comparison could get wacky.. Am at work now so havent really
checked the code, but my initial guess is that the hardware timer
should never be a problem, of course if the clock freq. is to high for
us to get enough resolution in clock ticks... But that threshold
should be pretty easy to calculate.. Once again, dont have access to
my code so cant do the calculations now.. But will look into it later
today.. But my guess is that it should be possible to solve this in
RAM instead of using hardware registers..

bullet 2 (Rewrite delay function):
By creating a delay function that internally is using a timer/clock
interface we should also be able to skip that the delay function is
hogging a HW timer..

bullet 3 (Add macros(defines) for calculating correct clock init
values so a user only needs to define clock freq. )
Pretty selfexplanatory..


This way, only one 8-bit HW timer is necessary for all uip
implementations, leaving all other HW timers free to use.. And using
an 8 bit timer should give us maximum device support. (since not all
devices support 16bit timers).

[Jonas Finnemann Jensen]

Well, I don't have much experience with HW timers, however, I can't see any reason to why it should ever become a problem to use an 8 bit timer... As long as you're using a software prescaler after woods...

However, if you have 16bit timer sitting around doing nothing, would I have 255 times as few interrupts if I used it as timers compared to using an 8bit timer... So using a 16bit timer, if available and not used for anything else, could enhance performance and powerusage if the device is brought to sleep... Right?
(Disclaimer: I don't have much experience with AVR, so let me know if I'm wrong).

Anyway, we don't have to implement the 16bit support right away, It'd just be nice to have in future...

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

I agree with what you said... We can use the 8bit time without problems,
it just need another overflow calc, etc... (I think)
Just for now I continue working over the posted code... hope to have
news soon.

Regards,

--
Jonathan Granade
WebCom-Design

[Jesper]

yeah, thats right.. It would mean that we get more interrupts.
Actually didnt think of the performance issue myself so good point...
But thinking about it I dont think that matters since we would get the
same interrupt times (atleast with my implementation) regardless of
8bit/16bit..
We get an interrupt every time we get a system tick (in my impl. every
5ms). That interrupt would therefore be the same regardless of timer
reg. size.

I did the math now and if we use a HW prescaler of 1024 and a system
tick resolution of 5ms then no SW prescaler is necessary unless you
have a clock freq. >52,22 MHz (wich is not very likely)

I calculated this as:
F_CPU = 1024 / (0,005 / 255)

where 1024 is the HW prescaler, 0,005 is the clock resolution and 255
is the maximum value of the 8bit timer registry.

So in my opinion this should show that there is no difference, either
from a CPU load or a power consumption perspective.
The Interrupt times are the same..

If we can assume there is a 1024 HW prescaler in all devices..

/Jesper

> > devices support 16bit timers).- Dölj citerad text -

[Jonas Finnemann Jensen]

Okay, I'm not sure exactly what you mean, and/or how you plan to implement it.

lets I have a micro processor running 10MHz (just a number that easy to work with).
Then with a HW prescaler of 1024 (which I think most devices have, atleast all of them with enough memory to run uip) the HW timer will have a tick with frequency of 10MHz/1024 = 9.77 kHz.
So each HW timer tick is ( 10MHz / 1024 )^-1 = 102.4 µs.
Thus with an 8-bit timer we'll have an overflow every 26.112 ms, this overflow we'll use the generate an interrupt from which we'll update software clock variable with a software scaling.

In pseudo code I was thinking something like this:

uint16_t global_datetime = 0;

void clock_init(){
    //Setup interrupt
    //Setup prescaler
    //etc
}

ISR(timer over flow){   //If using larger timer register generate fewer of these interrupts
    global_datetime += 1;
}

uint16_t get_time(){
    return global_datetime;   //If timer register was bigger we might want to divide and add it here as well.
}

This would give us a timer resolution of 26.112 ms, and a global_datetime clock overflow every 102.4 µs * 255 * 2^16 = 28.52 min. And with every clock overflow there's a risk some of clocks freeze, right? (since if an uip software clock is reset at 2^16 - 1, then it wont expire anytime soon).
However using a 32 bit global_datetime variable would postpone this issue 102.4 µs * 255 Ø 2^32  = 3.55 years.
But I guess the question is how long time do we need to anticipate that any users want their servers running?
I'd like a 32 bit timestampe with a resolution of 1 secound starting from the 1st of Januray 1970 :)
(But I guess it's not good either since uip likes to time things down to 500ms).

Do you have a different idea, on how to implement it? How long time should the software timer run before generating an overflow, that AFAIK could kill uip?

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Jonas,

Very interesting email and point of view... but I think that the timers
should be used to handle the uip_periodic function because we cant have
confidence on this to use as a real clock... we need to use a NTP client
and then we are free of problems.
A simple timer to count around 5 mins and then sync with a NTP server
and start again ? I think that should work.
I think I have a NTP client code anywhere here... I will look for it and
send it to you to take a look.

Regards,

--
Jonathan Granade
WebCom-Design

[Jonas Finnemann Jensen]

well, maybe you're right if users/developers want a unix timestamp for their app they should probably use NTP... However, I think we should implement avr-uip so that it requires access to an ntp server, this would limit usage on non-internet network, like LAN without router or DHCP...

We need a timer for the arp-expire and uip_periodic, I assumed we'd make those timers using the timer library in uip, by implementing the clock interface, right?
http://www.sics.se/~adam/uip/uip-1.0-refman/a00157.html

The only problem I can see is that at some point the "clock_time_t" will have an overflow, which may cause periodic errors.

I don't know if the timer library in UIP is used anywhere else then in the main.c examples... If so we should be able to remove the timer library, but I don't know if we want to do that... There's probably a lot of apps out there that depends on it, and a small timer library probably wont hurt us... If we can just find a good resolution for the software clock...
One idea would be to use a 64bit variable as "clock_timer_t", but it feels like a waste of memory...

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Exactly Jonas, I think we will use the timer library to do those
timers... when I mentioned ntp server just was to add a "live" clock to
the user, because any of those timers will be 100% perfect, they will
fail sometimes... also, the ntp server will be done like an app I think
? anyway, that doesnt matter now.
I like your idea, I think that it will work and also, I agree that using
a 64bit variable will be a waste of memory...

--
Jonathan Granade
WebCom-Design

Jonas Finnemann Jensen wrote:
> well, maybe you're right if users/developers want a unix timestamp for
> their app they should probably use NTP... However, I think we should
> implement avr-uip so that it requires access to an ntp server, this
> would limit usage on non-internet network, like LAN without router or
> DHCP...
>
> We need a timer for the arp-expire and uip_periodic, I assumed we'd
> make those timers using the timer library in uip, by implementing the
> clock interface, right?
> http://www.sics.se/~adam/uip/uip-1.0-refman/a00157.html

> <http://www.sics.se/%7Eadam/uip/uip-1.0-refman/a00157.html>

> > <mailto:jdere...@hotmail.com <mailto:jdere...@hotmail.com>>>

[Jonas Finnemann Jensen]

Okay, I think we should just go with a bit-size that gives us around the 5 min you were taking about...

By the way, I read into the timer.c library and I don't think an overflow would kill it... In case:
t->interval = 1000;
t->start = 65000;
//And we're working with a clock_timer_t at 16bit, an overflow causing the time to be say 1000 next time it's checked whether the timer has expired, would still cause it to expire, since it's checked using:
  (clock_time_t)(clock_time() - t->start) >= (clock_time_t)t->interval;

Am I right that it would yield:
mod(1000-65000;2^16) >= 1000
similar to:
1536 >= 1000

So it was just me who imagined that an overflow would cause problems, right?
Sorry about that, I should have checked the source twice before assuming that an overflow would cause problems...

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Jonas,

I will go into the code and check what you say... I'm a bit confused...

BTW, about my other problem... I'm finally trying with psock :( because
the other way didnt work... but I'm using more than 2k of sram (im using
atmega32 with 2k of ram)... I checked with avr-size that I have a big
(really big) .bss section... how can I minimize it?

Regards,

--
Jonathan Granade
WebCom-Design

> <mailto:jonatha...@gmail.com

[Jonas Finnemann Jensen]

I will go into the code and check what you say... I'm a bit confused...

Nevermind, it was me who got something wrong... There's no problem in having a clock that counts to 5 minutes and resets till zero...

BTW, about my other problem... I'm finally trying with psock :( because
the other way didnt work... but I'm using more than 2k of sram (im using
atmega32 with 2k of ram)... I checked with avr-size that I have a big
(really big) .bss section... how can I minimize it?

That's pretty much, I have an atmega644 with 4KiB ram and I'm barely using 1,6KiB .bss...
According to http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
.bss is:

Uninitialized global or static variables end up in the .bss section.

I suppose you may have some configuration error, maybe you have a 512 bytes file buffer for each connection and uip configured to 3 or 4 connection... Just a guess... Try minimizing the amount of connections as it may multiply the memory reserved for uip_tcp_appstate_t

--
Regards Jonas Finnemann Jensen.

[Jesper]

Sorry about the delay, have´nt been home for a couple of days so wasnt
able to read your replies until now.
But regarding the timer discussion I think you got it right. I have
always been under the impression that the uip timer is not a real
system clock (And would probably be very very bad at it) and is only
used as a way for uip to use the same resources for all timeout
counters..

But you guys seem to have come to the same conclusion.. So I dont have
anything to add here..
I think the general concensus is that we should use an 8bit HW timer.
Regarding the 5min scope I dont think that really mattersthat much,
what matters more is the clock resolution and then we use enough
memory that would make it impossible for the clock to overflow twice
in one timeout so to speak..
Then probably a 5min scope is probably a good choice.. Atleast until
we add more apps that would require a longer timeout.. Then again, if
that would happen perhaps we should use an external clock circuit for
that..

BTW, about my other problem... I'm finally trying with psock :
( because
> the other way didnt work... but I'm using more than 2k of sram (im using
> atmega32 with 2k of ram)... I checked with avr-size that I have a big
> (really big) .bss section... how can I minimize it?

yeah, just as Jonas mentioned, experiment with both number of live
connections and also the UIP_CONF_BUFFER_SIZE,
I am using an atmega16 with only 1K RAM and after some tweaking I got
the RAM size down to about 900B for uip, so fitting uip into 2K should
be relatively easy..
Another way to minimize RAM is to disable UDP and client connections
if you dont need them..

[Jonathan / WebCom-Design]

Glad to hear from you Jesper! hope all is ok there!

I think that we should go ahead with the 8bit hw timer, I'm reading
about "real time clocks" (DS1307), so we can add support for it without
ntp too... just if somebody want to have a real clock into the system.

I was going to add to the todo list the "crontab" support... what you
think? I think that any webserver or internet server should have it..
it's really good to use with the timer support.

About my problem, I'm about crying... I tried using the simple http
server from jonas and the webserver example from uip1.0 with psock, I
fixed the SRAM problem (Thanks for the help :) but it doesnt work...
with the uip1.0 example I receive a connection reset on my browser...
and with the simple http server from jonas the browser just keep loading
the page and never show anything...

--
Jonathan Granade
WebCom-Design

[Jesper]

Well, crontab or scheduled activities I would put under applications..
So why not?
However I would put it as a low priority at this point..

But my initial guess is that even if we were to implement a real
system time in SW I dont think it would be good enough for scheduled
tasks..
I think cpu clock is to irregular for that to be doable (maintain
correct time over longer periods). I think the solution there is for
an external clock circuit..

Regarding NTP and internet webservers, I am not too sure how we should
tackle this.. According to uip documentation uip is not designed for
large networks and should only be used on a local network.. Then there
is the issue if we really should recommend users to use the SW online,
with "illegal" MAC adresses and things like that..

/Jesper

On 4 Maj, 01:06, Jonathan / WebCom-Design <jonathan.web...@gmail.com>
wrote:

> > if you dont need them..- Dölj citerad text -

[Jonas Finnemann Jensen]

Regarding NTP and internet webservers, I am not too sure how we should
tackle this.. According to uip documentation uip is not designed for
large networks and should only be used on a local network.. Then there
is the issue if we really should recommend users to use the SW online,
with "illegal" MAC adresses and things like that..

Won't people always access the internet through a router... Either their own or a router at their ISP... I don't think there's much chance that the worlds internet browsers will ever get to know the MAC address of the server then...
I think it's only recommended for small networks because the MAC table in uip is rather limited... Using it on a large networks connected with switches would require a large MAC table which is probably not available on most microcontrollers... But who knows maybe the lack of a tcp window creates an issue when communicating over optimized lines such as provided by most ISPs today...

--
Regards Jonas Finnemann Jensen.

[Jesper]

That is true.. But I was thinking more in the lines of that our MACs
are illegal by law.. I am no expert in those standards but I believe
all devices which are meant to be used in a public environment must
have a valid MAC adress by law..
Allthough I am not sure about that at all.. So perhaps we should just
go ahead regardless.. They dont seem too concerned about it in the uip
documentation so perhaps its not that big of a deal..

And moreover the enc60j28 has filtering capabilities so atleast with
that circuit alot of the traffic on the internet would be stopped at
HW level in our case so it shouldnt pose too much problems with
processing unwanted packets..

> > > - Visa citerad text -- Dölj citerad text -

[Jonas Finnemann Jensen]

That is true.. But I was thinking more in the lines of that our MACs
are illegal by law.. I am no expert in those standards but I believe
all devices which are meant to be used in a public environment must
have a valid MAC adress by law..

I think this is something we should look into later on... But definitely something that would be interesting to investigate...

However, I doubt that it's illegal by law, if so we could be arguing that putting your device behind a router means that it's not directly connected to the public network...
Besides the internet is IP based not ethernet based, so doubt there's any legal problems by using random MAC address... It might not be standard compliant by it's not a crime to break standards, Microsoft does it daily :)
(Okay, bad example as they have been convicted for monopoly abuse)

--
Regards Jonas Finnemann Jensen.

[Jesper]

>It might not be standard
> compliant by it's not a crime to break standards, Microsoft does it daily :)
> (Okay, bad example as they have been convicted for monopoly abuse)

hehehehe... true..true...

btw, I will also put up filtering implementations in the todolist...
I think it should probably be of a higher priority than some other
things... (apart from the initial organisation and making a basic
functional release)

[Jonathan / WebCom-Design]

Guys, sorry by the delay on reply...

I think that the "ilegal" mac addr will not be a problem until someone
try to use it for bussiness purposes... anyway I think that the problem
will be with him, not with us if we put a big "NOTICE: This software is
just for home purposes"...
Anyway, as Jesper said, it's for local network use, but I plan to use it
over the internet too, I mean... I will connect this to a local network
but with external access as a private server for a few people... you
think that it's impossible because the ARP table?
The ARP table need to save all the road to the client? so, if I'm in
Argentina and I want to open the Jesper device, it should save all the
way from me to him? maybe it's an stupid question... but im confused...
besides that exist the max connection problems, that's what I say a
private server, if any person want to use it only by him... it should
not be a problem... (I think?)

Also, I think that the filtering is the most important thing now... I
dont see too much info about this, and I think that it helps to the
device works... if it filter any packet except from port 80 (for
example)... it will help.

I continue figthing here with all of this... hope to have a release soon

Regards,

[Jonas Finnemann Jensen]

ARP table is not a problem... When the traffic goes through a router your device only needs to know the MAC address of the router...
But if you were on a network with 300 computers connected with switches (not routers) the small ARP table might cause minor performance problems... But nothing big :)
I think that could be why it's not recommended for large networks...

By the way, if this project goes well I plan to be running it as a webserver on the internet too...

--
Regards Jonas Finnemann Jensen.

[Jesper]

Well, I think we would also have performance issues when connecting it
directly to a public IP. Since as it is now all packets must be
processed in SW and in an environment as the internet you have alot of
traffic that is not directed at specificly your ip and specificly port
80. Meaning that the uC must handle all these "scrap" packets aswell,
even if it means just to throw them away. So that is another reason
for packet filtering in HW (and possibly another reason for why uIP
and uC´s is not recomended for public networks).

>The ARP table need to save all the road to the client? so, if I'm in
>Argentina and I want to open the Jesper device, it should save all the
>way from me to him?"

No, the ARP table is just a kind of buffer table for mapping IP
addresses to MAC addresses. When you need to send an IP packet you
first look in your ARP table, if you dont have the MAC address saved
for that particular IP you would need to do an ARP request (ask "Who
has IP ....")
So the ARP table is only used so that you dont have to ask for a device
´s MAC address every time you want to send a packet. The bigger ARP
table, the fewer times you have to ask for the MAC address of the
recieving host.
In reality this means that if the device is NOT on the same subnet as
yourself, then the MAC address requested is the address for your
default router.

Hope this brings some clarity for you..

/Jesper

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

[Jonas Finnemann Jensen]

Well, I think we would also have performance issues when connecting it
directly to a public IP. Since as it is now all packets must be
processed in SW and in an environment as the internet you have alot of
traffic that is not directed at specificly your ip and specificly port
80. Meaning that the uC must handle all these "scrap" packets aswell,
even if it means just to throw them away. So that is another reason
for packet filtering in HW (and possibly another reason for why uIP
and uC´s is not recomended for public networks).

Are there any packages not addressed to me between me and my router, if I am the only one using that router?
Besides wouldn't the router know my MAC address and won't enc28j60, with filtering enabled, filter out packages not relevant for me...
Even if there was two PCs and the uip-device connected to the router wouldn't the router still address the packages correctly (with MAC address)?
I think it will?

Well, I guess we'll see when we've got a stable port :)

--
Regards Jonas Finnemann Jensen.

[Ben Zijlstra]

Hello from Holland

 

Have followed the mail exchange with great interest.

 

Here I got an Atmega644 with RTL8019as and a SD-card 512 MByte running with uIP. Think it is version 0.9.

Atmega644 is running at 20 Mhz.

 

And at this link some info about the ENC28J60 with Atmega168.

 

Very much doubts about the filtering. I think it is not working.

 

http://members.home.nl/bzijlstra/software/examples/enc28j60.htm

 

Ben Zijlstra

Ben’s HobbyCorner

 

 

 

---

Van: avr...@googlegroups.com [mailto:avr...@googlegroups.com] Namens Jonas Finnemann Jensen
Verzonden: dinsdag 6 mei 2008 22:23
Aan: avr...@googlegroups.com
Onderwerp: Re: Action points/ TODO lists?

[Jesper]

1.

>Are there any packages not addressed to me between me and my router, if I am
> the only one using that router?

No.
I was talking about connecting the uC direcitly to a public net. If
you have a router, the router will "filter" out all data.

2.

>Besides wouldn't the router know my MAC address

yes.

3.

>won't enc28j60, with filtering enabled, filter out packages not relevant for me...

Yes, it will filter out all layer 2 data not relevant to you.
But on internet alot of data is broadcast data, directed at all hosts
in the same subnet. So with no router in between your uC would have to
process a packet for every broadcast packet you recieve, which is
alot.. (Remember that ARP is handled in uC so all ARP requests (which
is sent to broadcast MAC) would have to be processed and then likely
discarded.

4.

>Even if there was two PCs and the uip-device connected to the router
>wouldn't the router still address the packages correctly (with MAC address)?

I am not sure I understand the question, do you mean two hosts + uip-
device in your LAN and these connected to a router, which in turn is
connected to the internet?
What do you mean by address the packages correctly?


All this aside, it will still work when connected to the internet, but
the uC would have to work harder to process all packages when on a
public network.
This is the beauty with the enc28j60 eth device. As to my knowledge
this is the only ethernet device capable of hardware filtering. This
makes that circuit ideal for uC applications.. It can filter both L2
data (i.e you can choose to filter out all incoming packets with a
specific MAC, or only accept packets from a specific MAC).
And there is also a custom filtering function where you can choose
15byte (or something like that) to match against a filter. Using that
function we could choose to filter out all packets not using for ex.
IP protocol and not directed at port 80.


With regards..

[Jonas Finnemann Jensen]

But on internet alot of data is broadcast data, directed at all hosts
in the same subnet. So with no router in between your uC would have to
process a packet for every broadcast packet you recieve, which is
alot.. (Remember that ARP is handled in uC so all ARP requests (which
is sent to broadcast MAC) would have to be processed and then likely
discarded.

Well can't one host content through a router? and only have the router send information relevant for your application to your uip-device...
Sorry if I'm not too familiar with internet infrastructure...

--
Regards Jonas Finnemann Jensen.

[Jesper]

>Sorry if I'm not too familiar with internet infrastructure...

No problem, next time its me who might need some explaining..

>Well can't one host content through a router? and only have the router send
>information relevant for your application to your uip-device...

Yes, that would be the preferred way of doing it. That is also what is
recomended by uIP documentation.. So puting your uC behind a router
and then portforward to the uC would be ideal.

But if one would want to connect the uC directly to a public ip, then
some filtering would probably be needed..

> ...
>
> läs mer »- Dölj citerad text -

[Jesper]

Ben Zijlstra wrote:
>Very much doubts about the filtering. I think it is not working.

Well, seems that the people in that project havent gotten it to work..
But I have read the specs. for the enc28j60 circuit and I dont think
it will be to much trouble implementing it..
I have already played around with some of the filters and it should´nt
be to hard to implement all of them.
The "magic filter" as they call it would probably take some more time,
but that is not that complicated either..

On 6 Maj, 23:17, "Ben Zijlstra" <bzijls...@home.nl> wrote:
> Hello from Holland
>
> Have followed the mail exchange with great interest.
>
> Here I got an Atmega644 with RTL8019as and a SD-card 512 MByte running with
> uIP. Think it is version 0.9.
>
> Atmega644 is running at 20 Mhz.
>
> And at this link some info about the ENC28J60 with Atmega168.
>
> Very much doubts about the filtering. I think it is not working.
>
> http://members.home.nl/bzijlstra/software/examples/enc28j60.htm
>
> Ben Zijlstra
>
> Ben’s HobbyCorner
>
>   _____  
>

[Jonas Finnemann Jensen]

So puting your uC behind a router
and then portforward to the uC would be ideal.

But if one would want to connect the uC directly to a public ip, then
some filtering would probably be needed..

Okay, I thought there'd always be a router if not your own then one from your ISP...

--
Regards Jonas Finnemann Jensen.

[Jesper]

> Okay, I thought there'd always be a router if not your own then one from
> your ISP...

Thay have routers too of course, I guess each ISPs infrastructure is
different, but I would guess that L3 handling to each host would be
way to expensive...
You can see this on your netmask, I have a public NM of 255.255.240.0
meaning that 4095 hosts exists on the same subnet as myself...