Hi all,
I'm making port avoiding dynamic memory allocation (to avoid
fragmentation). Thus I need to allocate system objects from pool.
Could you provide me formulas how to calculate required pool sizes for each
object
based on options from opt.h ?
I did short examination of lwip code and
found th
Hi all,
I faced with problem and founded that this issue was discussed
vigorously at "[lwip-users] about memory problem" in 2008 and still remained
opened !
On Thu, 17 Jul 2008 11:14:32 +0100 Kieran Mansley wrote:
> On Thu, 2008-07-17 at 17:56 +0800, yueyue papa wrote:
>> If onlye enable
>> */
>
I've completely broken my brain on memory mechanisms used in lwip.
It's totally unclear are mem and memp independent mechanisms, or mem
utilizes memp, or memp uses mem, or they are cross-references each
other ? Custom pools are part of pools (memp), or pools are part of
custom pools ?
There are co
;t help in case when mailbox itself allocated
in RTOS memory and RTOS return just pointer (sys_mbox_t) of fixed
size. In such a way, I have to implement own independed pool mechanism included
in port for that RTOS.
> jblackarty wrote:
>> It's totally unclear are mem and memp independent m
> I don't think I have thought that through fully, but mboxes are
> only created in 5 different sizes (at maximum), so it shouldn't be
> too hard to switch over mbox size to know the pool to allocate from?
No! In general case, sizes are NOT different. At compile-time macro
expansions define each s
>> No! In general case, sizes are NOT different. At compile-time macro
>> expansions define each size, but at run-time sys_mbox_new() cannot match
>> given
>> numeric value to one of macros if their values are equal. That's the
>> problem !
> What's the problem there? You can just use one pool th
Hi all,
1. How to make driver to be notified when application sets it's interface
up/down ? It's needed to remove unnecessary system load by disabling
transmit path in hardware. There are LWIP_NETIF_STATUS_CALLBACK and
LWIP_NETIF_LINK_CALLBACK capabilities exist but seems that they
intended to be
> While multiple ports use separate thread for packets input, it is not
> the only way LwIP can work. If yor driver operates in tcp_ip thread
> there is no need for it to be thread safe.
I know. I implicitly meant only case when NO_SYS=0 (that is multithreading)
> If u use separate threa
> thera a
> See my last mail (2.5 hours ago) about these (short summary: #1 can
> currently not be fixed, #3 is already fixed in git).
My message was sent earlier but delayed by some reasons.
Thank you for answers. I prefer to use stable releases and will wait
for official release resolves issue #3. I hope
Hi all,
I've ported lwip to FreeRTOS-MPU (ARM Cortex-M3, GCC) and suddenly
found that lwip design violates FreeRTOS memory access
restrictions. The problem is that lwip tcpip thread accesses local
variable allocated on stack of application thread which uses Netconn
API. FreeRTOS-MPU protects threa
Hi all,
Current verson of http://lwip.wikia.com/wiki/Porting_for_an_OS#cc.h page
containts a statement regarding structure packing:
"The common case is using Ethernet interfaces and MEM_ALIGNMENT=4. Ethernet
header without VLAN is 14 bytes, so if you can/must have ETH_PAD_SIZE=2, then
IP headers
> Whoever wrote that (I'm too lazy to check the wiki history right
> now) thought (or maybe even checked) that inside protocol headers,
> all members are aligned, so when the start of a protocol header is
> aligned, you wouldn't need packing.
Structure alignment and packing of internal members are
I think we must define a term for "lwip context packing" :) That
phrase on wiki may be corrected to "you may not need whole structure
alignment" instead of "you may not need packing", because structure packing is
mostly refer to structure members packing (removing pads) which is
essential for lwip.
> Question: is it important for your application thread and the tcpip thread
> to be in different protected memory regions? is it possible for that
> memory to be accessed by both threads?
As I said already, I did it so. I've placed application thread stack
in separate memory region and added this
I would like to add a port and ethernet driver too.
But I need help to understand why it works unstable or what's wrong
with it. If I succeed to make it work, I'll be very gratefull and
promiss to maintain it for at least 1-2 years. Even if I will not able
to do it so long, it means that platform/r
> So while I also think that protecting the thread's stacks against
> each other would be a good thing, the lack of this protection
> doesn't seem to be the cause of your problems!
This is the most interesting thing. How can can I find out cause of
crash in such complex system. I haven't professio
> Hi,
>
> do you mean this situation?
>
> Thread A = tcpip thread - stack protected by MPU, only A and
> privileged mode can access it
> Thread B = user thread - stack protected by MPU, only B and privileged
> mode can access it
> [...]
Yes.
> The privileged kernel does not use the task stack for
>>> The privileged kernel does not use the task stack for its own
>>> variables/return
>>> addresses/etc.
>>
>> Richard, I'm going to surprise you. It does!
>
> Of course - you are right when you make API function calls. In my mind
> I was just thinking about the tick interrupt and context swit
> I'm not sure what you're saying here: you found a mistake in Richard's mind?
> :-)
I was thought that I found. It turned out to be just only incorrect
expression of thought in context of our discussion. Anyway, it means
that I'm still right claiming that currupting of task stack is
dangerous fo
> What is wrong with you using FreeRTOS. I have been using it on
> different architectures (ARM, MIPS, PIC24) for many years and it is
> working great. It is not so good to use negative words in public
> domain. I think we should respect each other, especially for those
> who make contributions for
Oops !.. Seems like I found a serious mistake in my configuration which
relates directly to kernel stability ! But I have no time anymore and
have to run away. I'll be back on monday !
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nong
Yahoo ! Sorry for offtopic, but I fixed it and program works super
stable now (at least, I'm not able to crash it by hands since now).
Anyway, I'm going to try modify lwip in order to avoid accesses to
other thread's stack...
___
lwip-users mailing lis
Title: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after debugger break
I have to say that ST's demo example works bad. I don't know what exactly they did wrong (incorrect lwip configuration, driver, peripherials/clocks initialization or something else), but I experienced pro
you solved issue. My congratulations :)
Hello jblackarty
I'am interested in your port of the stack on the STM32F207 i currently use 1.3.2.
Did you port 1.4 to the STM32F207 ?
If so can you share you port / project ?
I am using IAR version 6.4.1 but soon going to update to the latest rel
24 matches
Mail list logo
