tests: remove ticker test #4427
Conversation
This is temporary, as this test does not fit to some 16kB RAM devices. This requires few more steps: some small devices are using big async HAL structures, RTX changes increased the RAM footprint, plus this test seems to be too big. With all these, it won't fit in RAM regions for some devices.
|
@0xc0170 sorry but what is the actual benefit of removing the test ? Isn't there a way to mark the test as not applicable to 16KB targets ? |
|
Currently the amount of memory in the device is unknown to the tests. |
Test should be applicable to 16kB ! This is testing generic functionality, thus we need a test to do that. if there are two or more tests, should test all public API. and for all targets. Plus what @sg- wrote above. we will need to address this. We will provide more details regarding the footprint of some targets. I was looking this morning into NUCLEO_F070RB specifically, it enables async, and uart is consuming like 500 bytes, plus not certain why for IAR we could see SPI objects in for this ticker test (is not used anywhere ,but SPI with async support was shown in the map file with transactions , allocating 168 readwrite data). You should be able to reproduce on latest master. |
|
@0xc0170 I understand the issue and acknowledge. it. |
|
Currently no code comes to master with any failing tests. Its to hard to manage false positive, false negative, system issues, etc. Having to recall or make judgements about what tests should pass or fail for a device, its just easier to make it all green. If that means 2 test images in some cases where RAM consumption is to much, fine. It also forces us to look at the root cause. @0xc0170 pointed out a few things we found from this regarding code not getting garbage collected by the linker and @pan- identified #4363. So in general, its really painful, but the goal is to focus and fix the real problems rather than let peoples judgement dictate whats good enough. Hope this makes sense and open to contributions to or suggestions to make it better meaning faster code integration with higher confidence. |
|
@sg- Ok that is therefore related to CI - this was not clear so far |
|
Sounds like we lack of such feature in tools where we could skip selected testcases until fix is available |
This is temporary, as this test does not fit to some 16kB RAM devices. This requires few more steps: some small devices are using big async HAL structures (or other issues in the targets code that we will need to identify), RTX changes that are coming in have bigger RAM footprint, plus this test seems to be too big. With all these, it won't fit in RAM regions for some devices.
Removing tests is not a solution. Trimming this down should come asap.
@pan- @sg- @studavekar