Fix RToS Update #2091
Fix RToS Update #2091
Conversation
There was a problem hiding this comment.
Hello, @Ralim.
I was catching up with the recent changes, and now I'm just very curious about Makefile update, so I have a couple of questions (only for my own better understanding).
I will be very thankful, if you will find a bit of time to explain these updates to me, thanks in advance:
| @@ -425,6 +425,7 @@ CHECKOPTIONS=-Wtrigraphs \ | |||
| -Wmissing-field-initializers \ | |||
| -Wshadow \ | |||
| -Wno-unused-parameter \ | |||
| -Wno-undef \ | |||
There was a problem hiding this comment.
I will try to find some time to make a build without this option to check myself, but what exact warnings you would like to hide with this flag?
I understand how annoying some of the warnings may be, but I personally prefer better to see them and hoping to deal with them some time later, than hiding completely.
There was a problem hiding this comment.
FreeRTOS added two #if checks around the ticks count but it also breaks if you define both (even if one is 1 and one is 0). But this warning trips because one of them isn't defined.
There was a problem hiding this comment.
Id love a better solution to this btw, just didnt find one, and didn't appreciate the screen of warnings 🙃 . One option would be to only add this when compiling things that include the freertos headers.. but thats most of the binary :(
| @@ -454,6 +455,7 @@ CFLAGS=$(DEV_CFLAGS) \ | |||
| -D${COMPILER} \ | |||
| -MMD \ | |||
| -std=gnu11 \ | |||
| -g3 \ | |||
There was a problem hiding this comment.
I haven't checked the sizes of output binaries closely yet, and considering there is a process of stripping/converting firmware files, this shouldn't hurt, I guess, but why exactly you did enable debug symbols?
There was a problem hiding this comment.
This really only affects the .elf files, so that I get proper symbols when debugging.
There was a problem hiding this comment.
Thank you for the information. Just one more thing:
I get proper symbols when debugging.
Do you just load produced .elf files via gdb-arm-none-eabi/gdb-multiarch and debug them "statically"? Or do you have some additional special setup to get dynamic stepping? I'm curious, because I have that question anyway for a long time, but always forgot to ask.
There was a problem hiding this comment.
I load them onto the device over SWD/JTAG (depending on the device). Using usual openocd and gdb process for embedded, and then step through it all. Sometimes I'll use the segger tools (as I have a JLink) but not often.
|
Hi,
On Mon, Mar 03, 2025 at 02:13:37PM -0800, Ivan Zorin wrote:
> @@ -454,6 +455,7 @@ CFLAGS=$(DEV_CFLAGS) \
-D${COMPILER} \
-MMD \
-std=gnu11 \
+ -g3 \
Thank you for the information. Just one more thing:
I get proper symbols when debugging.
Do you just load produced .elf files via gdb-arm-none-eabi/gdb-multiarch and
debug them "statically"? Or do you have some additional special setup to get
dynamic stepping? I'm curious, because I have that question anyway for a long
time, but always forgot to ask.
Using JTAG/SWD to actually see what's going on with the target
(stepping, breakpoints, watchpoints, inspecting and changing
peripheral config registers, even calling individual functions
REPL-style) really helps a lot to save time on debugging.
No special equipment needed for that other than something that can
talk SWD with Arm targets and JTAG with RISCV (that something can be
just a FT*232H breakout board or SBC GPIO bitbanging even) but that's
really cheap, diverse and available.
OpenOCD is the tool I would suggest to talk to the debug adapters, and
GDB connects to it using the regular protocol.
HTH
|
Closes #2090
Closes #2089
Fixes task max priorities due to update to rtos related code earlier.
Tested on