Am 15.11.2021 um 18:03 schrieb Grant Edwards:
Is it required that sys_thread_t be a pointer or integer type?
The documentation doesn't state that. The example implementation at
https://lwip.fandom.com/wiki/Porting_for_an_OS#Threads shows it as a
struct, and in the freeRTOS port it's a struct.
Am 15.11.2021 um 15:53 schrieb Grant Edwards:
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
sys_arch_protect() and sys_arch_unprotect() is always called in
pairs with call order maintained.
So the requirement stated in the documentation that
SYS_ARCH_UNPROTECT Perform a "fast" set
I feel the port assumes thread creation should always be a success and if
fails then assert is called. So the return value is always non zero. I
believe this cannot be used in a production scenario where error needs to
be reported and mitigated properly depending on what kind of system are you
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> No, I am not assuming mutext required to be nested either.
but I thought sys_arch_protect/unprotect are required to nest?
> Infact my implementation had only simple lock unlock only. And as
> far as I know, lwip do not use nesting of lock, as
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> You can define it as integer or pointer based on your system.
Yes, I know I can.
I want to know if it is _required_ to be an integer or pointer.
> Its definately not a structure.
It definitely is a structure in the freeRTOS port which I was
You can define it as integer or pointer based on your system. Its
definately not a structure.
Regards,
Ajay Bhargav
On Mon, Nov 15, 2021, 10:36 PM Grant Edwards
wrote:
> Is it required that sys_thread_t be a pointer or integer type?
>
> The documentation doesn't state that. The example
Is it required that sys_thread_t be a pointer or integer type?
The documentation doesn't state that. The example implementation at
https://lwip.fandom.com/wiki/Porting_for_an_OS#Threads shows it as a
struct, and in the freeRTOS port it's a struct.
But the test code assumes it's a pointer or
No, I am not assuming mutext required to be nested either. Infact my
implementation had only simple lock unlock only. And as far as I know, lwip
do not use nesting of lock, as its obvious that not all system support
recursion.
And lev is usually common return value of isr flags when disable_irq
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> protect/unprotect is totally implementation dependent with only
> intention of providing exclusive access to network related operation
> to be performed without any context switching. You can do this by
> using a mutext in simplest way
Are you
protect/unprotect is totally implementation dependent with only intention
of providing exclusive access to network related operation to be performed
without any context switching. You can do this by using a mutext in
simplest way but you have to make sure ISR do not do any operation either
when
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> sys_arch_protect() and sys_arch_unprotect() is always called in
> pairs with call order maintained.
So the requirement stated in the documentation that
SYS_ARCH_UNPROTECT Perform a "fast" set of the protection level to "lev".
is incorrect
Hi Ivan,
I moved your callback up a little. Also, I see that your have both IPv6 and
IPv4 enabled. I will recommend disabling IPv4 in your lwipopts.h file
temporarily (by #define LWIP_IPV4 0) and see if you can get IPv6 to run by
itself first. Once you get that working, then you can consider
12 matches
Mail list logo
