Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixture: review proposal for #30594 #2

Closed

Conversation

tejlmand
Copy link

Proposal.

Signed-off-by: Torsten Rasmussen Torsten.Rasmussen@nordicsemi.no

@@ -1,5 +1,36 @@
tests:
drivers.gpio.2pin:
platform_exclude: nucleo_f091rc nucleo_l476rg nucleo_l073rz nucleo_f401re stm32mp157c_dk2 nucleo_f030r8 nucleo_g071rb nucleo_l053r8 nucleo_g474re nucleo_f334r8 nucleo_wb55rg rv32m1_vega nucleo_f746zg mimxrt1050_evk frdm_k64f disco_l475_iot1 nrf52840dk_nrf52840 nucleo_l4r5zi lpcxpresso55s69 nucleo_f429zi mimxrt1060_evk hifive1_revb nucleo_l152re
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is unmaintainable, but we can discuss it in dev-review.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compared to 20 duplicated files ?
I think I prefer adding a single board name here, instead of duplicating identical files everywhere.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

of course it might be possible to adjust testcase.yml scheme, so that if a platform in specifically mentioned further down, then it is automatically exclude here, but that would be an extension, but probably a valuable one.

Note, the reason I didn't line break, is because I'm unsure if the testcase yaml shema allows it, and / or if a proper yml sequence is allowed. So this was a quick way, to show the principle.

Copy link
Owner

@pabigot pabigot Dec 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is, instead of inheriting support for all existing tests that use fixtures by simply adding a fixtures include to the board, you have to edit every test that supports a specific fixture and add the board into the appropriate build option, trying not to corrupt the existing list when you do so.

Also the board-specific overlays providing support for fixtures aren't in the boards directory where people can find them, they're down under tests/common, are separate for each fixture, and do not indicate in the overlay what boards they apply to.

And if you want to change the pins associated with one fixture on one board, you have to change all the test configurations that use that fixture.

None of that is insurmountable, but I don't consider it an improvement over the current content of zephyrproject-rtos#30594.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update.
It is possible to make new lines, which help on the long lines, but doesn't solve the issue with having to specify the board both in platform_exclude, and then a platform_allow.

But would like your opinion on this, if there can be an platform_allow_exclude_others kind of entry.

This is the main part of the proposal.
Keeping test fixture overlays under tests, in structure similar to what
is described in:
https://docs.zephyrproject.org/
latest/guides/dts/howtos.html#set-devicetree-overlays

by using:
> create a boards/<BOARD>.overlay file in the application folder, for
> the current board

Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
@tejlmand tejlmand force-pushed the reviews/30594_proposal branch from 3d91fb0 to 9f97764 Compare January 4, 2021 09:56
pabigot pushed a commit that referenced this pull request Mar 23, 2021
Added function to calculate channel identifier value
required for Channel Selection Algorithm #2.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
pabigot pushed a commit that referenced this pull request Mar 26, 2021
The fatal log now contains
- Trap type in human readable representation
- Integer registers visible to the program when trap was taken
- Special register values such as PC and PSR
- Backtrace with PC and SP

If CONFIG_EXTRA_EXCEPTION_INFO is enabled, then all the above is
logged. If not, only the special registers are logged.

The format is inspired by the GRMON debug monitor and TSIM simulator.
A quick guide on how to use the values is in fatal.c.

It now looks like this:

E: tt = 0x02, illegal_instruction
E:
E:       INS        LOCALS     OUTS       GLOBALS
E:   0:  00000000   f3900fc0   40007c50   00000000
E:   1:  00000000   40004bf0   40008d30   40008c00
E:   2:  00000000   40004bf4   40008000   00000003
E:   3:  40009158   00000000   40009000   00000002
E:   4:  40008fa8   40003c00   40008fa8   00000008
E:   5:  40009000   f3400fc0   00000000   00000080
E:   6:  4000a1f8   40000050   4000a190   00000000
E:   7:  40002308   00000000   40001fb8   000000c1
E:
E: psr: f30000c7   wim: 00000008   tbr: 40000020   y: 00000000
E:  pc: 4000a1f4   npc: 4000a1f8
E:
E:       pc         sp
E:  #0   4000a1f4   4000a190
E:  #1   40002308   4000a1f8
E:  #2   40003b24   4000a258

Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
galak pushed a commit that referenced this pull request May 5, 2021
Reorder Channel Selection Algorithm #2 and Minimum Number of
Used Channels Procedure bits.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
@tejlmand tejlmand closed this Nov 28, 2024
@tejlmand tejlmand deleted the reviews/30594_proposal branch November 28, 2024 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants