Hello all,
Adam Baron wrote " I'm just a user, but I believe the core locking has to be
done on the port level. I did put it there in my case. Then assertion of is
core locked will tell you exactly what MQTT client functions need core to be
locked."
Do you have examples of what you are
That's great to hear.
Quite a lot of heap sources out there have some weird "feature" like
that. The more I dig into this the more different code I find which
does this.
If there were issues deep inside LWIP I would never find them. The
functionality is way too complex for me to troubleshoot it
Peter wrote:
>Does anyone know if LWIP's internal heap management has this issue
>
>https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/
Ehrm, that's newlib. Why should we have the same bug? Did you meet any problems
with the lwip heap? There are no known bugs
Does anyone know if LWIP's internal heap management has this issue
https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/
Basically, the workaround in that particular case was to malloc and
immediately free the largest possible block.
That was a bug in a commonly used
Hello,
I'm just a user, but I believe the core locking has to be done on the port
level. I did put it there in my case. Then assertion of is core locked
will tell you exactly what MQTT client functions need core to be locked.
Adam
ne 30. 4. 2023 v 11:55 odesílatel Christoph M. Wintersteiger <
