tasklwIP - A Lightweight TCP/IP stack - Tasks: task #7244, Add sys_arch_ticks/jiffies in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #7244: Add sys_arch_ticks/jiffies in sys_arch

Submitter:  Frédéric Bernon <fbernon>
Submitted:  Fri 24 Aug 2007 02:37:35 PM UTC
   
 
Category:  Platform ports Should Start On:  Thu 23 Aug 2007 10:00:00 PM UTC
Should be Finished on:  Thu 23 Aug 2007 10:00:00 PM UTC Priority:  1 - Later
Status:  Cancelled Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Closed Planned Release:  None
Effort:  0.00

Jump to the original submission

Sun 22 Feb 2015 09:12:22 PM UTC, comment #10: 

What's the purpose of this entry? We do have sys_now(), which is pretty much required when using certain features, so there should be no need for additional functions returning ticks/jiffies?

Closing as cancelled.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 29 Apr 2011 09:20:51 AM UTC, comment #9: 

I want to port lwIP to a LPC1768. The stack has to run without operating system. I know that I have to write a new ethernetif.c therefore, but what is about the sys_arch. Is there something to do too? Beacause I read, that in this case no semaphores etc. are needed. Is there a documentation, what I have to do to port the lwIP stack.

And yet another question. When I try to compile the project (I took the STM32-F107 implementation as a basic) everything is fine. But while linking the files, the sys_now() produces a linker error. And I have seen, that is just declared but never defined. Is this a systick or something that I have to implement by myself?

Thank You

Paul

Paul Preuß <ransepans>
Tue 18 May 2010 07:16:11 PM UTC, comment #8: 

Actually, I was about to work on this as I already saw the negative impact of timeouts not being called because sys_timeouts_mbox_fetch() didn't wait long enough (< 1ms) under high load (which made my watchdog fail to trigger).

However, I don't know when I find the time to do this and I don't want to hold back 1.4.0 for that. Also, as stated below, since this isn't strictly necessary, I'd make the new timing optional so that a port can chose between the old "sys_timeouts_mbox_fetch() returns the time it waited" and the new "calculate the time needed on our own".

Simon Goldschmidt <goldsimon>
Group administrator
Tue 18 May 2010 01:37:50 PM UTC, comment #7: 

This doesn't seem to be going anywhere, so removing from the planned release.

Kieran Mansley <kieranm>
Group Member
Mon 12 Nov 2007 10:55:57 PM UTC, comment #6: 

There is already sys_now() and sys_jiffies() defined in sys.h, but only used in some ports: perhaps we should remove them from sys.h?

About the initial purpose, if the first one is always a problem, the second one is already fixed with SNMP_GET_SYSUPTIME.


Frédéric Bernon <fbernon>
Group Member
Mon 12 Nov 2007 08:15:08 PM UTC, comment #5: 


> We don't have to get all breakage into 1.3.0 by any means, so
> lets delay this till the next release


Can we implement this (after 1.3.0) in a way that it can be used optionally? That way it wouldn't be so bad that we break ports again (with 1.4.0 or 1.3.1).

It would be an option: use return value of sys_sem/sys_mbox functions OR sys_uptime() to calculate the time (with the downside that the old code is not that accurate).

Simon Goldschmidt <goldsimon>
Group administrator
Wed 29 Aug 2007 09:02:51 AM UTC, comment #4: 

I'm agree, it's not to do for 1.3.0, I just wanted to not forget than, since it was "lost" inside some comments of bug #1902.

Frédéric Bernon <fbernon>
Group Member
Wed 29 Aug 2007 08:58:10 AM UTC, comment #3: 

We don't have to get all breakage into 1.3.0 by any means, so lets delay this till the next release - it's a reasonably complex change that we want to get right rather than hurrying through, so I'd rather wait till be have the time to do properly.

Kieran Mansley <kieranm>
Group Member
Mon 27 Aug 2007 06:26:16 AM UTC, comment #2: 

I kind of did the work already, but the 'wrapping and overflow' does need some attention... And it's far from complete, of course. Plus I don't really have much time currently :-(

All that makes me think it shouldn't be scheduled for 1.3.0. But on the other hand, we wanted to make all port-breaking changes in 1.3.0, so maybe we should include it?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 24 Aug 2007 03:29:34 PM UTC, comment #1: 

Yep, Simon's hard work in that bug sums it up really, particularly as he described in comment #21.

I don't think anyone thinks it's a bad idea - I think everyone thinks it's good, but someone just needs to find the time.

Wrapping and overflow are still a worry though. Maybe in the case of high res timers, we should just insist people lower the precision before exporting the "jiffies" to lwIP. It would only take a logical shift right, so not expensive.

Jonathan Larmour <jifl>
Group Member
Fri 24 Aug 2007 02:37:35 PM UTC, original submission:  

We have already talk in several threads to add such concept in sys_arch.

This feature could be used to fix:

- improve timeouts accurate (see https://savannah.nongnu.org/bugs/?1902 and some others).

- snmp_sys_time consumne lot of cycles for nothing (since, with current implementation, we have to call snmp_inc_sysuptime() each 10ms), which is not useful, since we could compute "sys_time" only when snmp_get_sysuptime is called (see https://savannah.nongnu.org/patch/?5785).

Nothing was really decide about that. Thoughts?

Frédéric Bernon <fbernon>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ransepans (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by fbernon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-22 goldsimon StatusNone Cancelled
        Open/ClosedOpen Closed
    2010-05-18 kieranm Planned Release1.4.0 None
    2008-03-25 kieranm Planned ReleaseNone 1.4.0
    2007-08-29 kieranm Priority5 - Normal 1 - Later

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code