You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm seeing some weird behavior in _open() (retarget.cpp:166) when running the example-mbedos-blinky example on EFM32 Happy Gecko. It looks to me like the sscanf() call on line 209 takes up several hundred bytes of stack space when trying to allocate a file handle for stdout. I assume some of this is buffers for the string, but it still seems excessive. I have not tested this on other platforms, so if someone were able to confirm this, that would be great.
Since EFM32 Happy Gecko only has 8 kB of RAM, it would be great if the stack usage could be reduced. Internally, sscanf calls strtoul() for actually storing the string value into the pointer, so by doing this directly, instead of going through sscanf, stack usage was reduced significantly in my tests. I have attached a patch below.
Testing
All testing was performed with armgcc 4.9.3 20150529 on OSX, running yotta build in release mode. I filled the stack with 0xCD, and looked at the maximum stack usage of example-mbedos-blinky. The stack runs from the base of RAM (0x20000000) to `0x20000800 in these tests.
Hi,
I'm seeing some weird behavior in
_open()
(retarget.cpp:166) when running the example-mbedos-blinky example on EFM32 Happy Gecko. It looks to me like thesscanf()
call on line 209 takes up several hundred bytes of stack space when trying to allocate a file handle for stdout. I assume some of this is buffers for the string, but it still seems excessive. I have not tested this on other platforms, so if someone were able to confirm this, that would be great.Since EFM32 Happy Gecko only has 8 kB of RAM, it would be great if the stack usage could be reduced. Internally, sscanf calls
strtoul()
for actually storing the string value into the pointer, so by doing this directly, instead of going through sscanf, stack usage was reduced significantly in my tests. I have attached a patch below.Testing
All testing was performed with armgcc 4.9.3 20150529 on OSX, running yotta build in release mode. I filled the stack with
0xCD
, and looked at the maximum stack usage of example-mbedos-blinky. The stack runs from the base of RAM (0x20000000
) to `0x20000800 in these tests.EFM32 Happy Gecko (target efm32hg-stk-gcc)
Lowest address touched originally:
0x2000028c
Lowest address touched with patch:
0x20000500
EFM32 Giant Gecko (target efm32gg-stk-gcc)
Lowest address touched originally:
0x2000250
Lowest address touched with patch:
0x20004b8
I.e. approximately 600 bytes of stack space is saved for both these devices.
Patch
The text was updated successfully, but these errors were encountered: