ARM-software / CMSIS_5

CMSIS Version 5 Development Repository
http://arm-software.github.io/CMSIS_5/index.html
Apache License 2.0
1.29k stars 1.08k forks source link

SVDConv do not generate SysTick_IRQn. #60

Closed David-Garcia-Polo closed 7 years ago

David-Garcia-Polo commented 8 years ago

some of our designs have no SysTick timers, but I have not found a way to describe in the SVD file that no sysTick is available. Header files generated by SVDConv.exe contain SysTick functionality. when our customers use it, it does not work (it is not there) and contact support.

We would like a way to have SVDConv not generate SysTick_IRQn. Maybe an svd extebnsion to level in SVD file?

ilg-ul commented 8 years ago

some of our designs have no SysTick timers

can you be more specific which one?

David-Garcia-Polo commented 8 years ago

Nordic Semiconductor nRF51822 device or nRF51422 device have no SysTick, neither the standard ARM nor any vendor SysTick.

ilg-ul commented 8 years ago

nRF51822 or nRF51422

ok, thank you.

just wanted to be sure I'll be able to avoid them completely.

David-Garcia-Polo commented 8 years ago

dont be so mean :)

ilg-ul commented 8 years ago

FYI, I've just completed the reference implementation of the CMSIS++ RTOS, and all time related operations, be it a simple osDelay(), thread preemption, blocking calls timeouts, thread usage statistics, etc are all based on SysTick, as they should be.

designing a Cortex-M device without a SysTick is like putting a large banner "don't try to use me with an RTOS, I'm not suitable for this".

salkinium commented 8 years ago

designing a Cortex-M device without a SysTick is like putting a large banner "don't try to use me with an RTOS, I'm not suitable for this".

SysTick is usually connected to the CPU clock, meaning if you want to sleep the CPU, there goes your SysTick. Replacing the SysTick with a low-power timer is a good idea for when you want to keep an accurate time base in low-power designs, but need to wake up periodically (ie. lower than typical RTC time periods).

There is more than one solution to designing an RTOS, you should see this as an opportunity, rather than a limitation.

ilg-ul commented 8 years ago

There is more than one solution to design an RTOS

the CMSIS++ RTOS design is quite elaborated, it specifies three clocks: the system clock (that counts ticks when non sleeping), the real time clock (that can be used while sleeping) and the high resolution clock (that counts clocks when accurate measurements are required). this does not mean that further improvements are no longer possible, but within limits. ARM invented SysTick exactly to help simplify software, and providing it in real devices is kind of a courtesy to developers. You might save a quarter of a microamp by designing proprietary hardware, but this will also require proprietary software, which adds to the total cost.

salkinium commented 8 years ago

this does not mean that further improvements are no longer possible, but within limits

Indeed, we're barely beginning to understand energy efficient software. Why would tick based scheduling be the most energy efficient way of scheduling? ;-P

but this will also require proprietary software, which adds to the total cost.

You will need new software to take advantage of energy-efficient hardware anyway. Just throwing an RTOS at it won't cut it. It's more of a brute force approach to the problem, which is quite a bit more complicated in detail. Just think of subtree clock gating and how that could be integrated into an RTOS. The "custom" timer is the least of your problems.

Don't loose track of what's ahead. This is the golden age of µC OS design. We are seeing whole new approaches to adding light-weight concurrency that are not thread based (coroutines, fibres), and integrating energy awareness into them. It's going to be EPIC.

</rave>

David-Garcia-Polo commented 8 years ago

as salkinium just defended, our design has a propietary timer that allows the core to sleep while counting. Therefore we do not have a systick.

ilg-ul commented 8 years ago

a proprietary timer ...

the CMSIS++ / µOS++ project is highly portable, and if someone will be interested to port it to Nordic devices, the solution is a copy/paste of the generic Cortex-M port-specific files (3 headers and one cpp) followed by an update to use the proprietary timer; I guess this shouldn't be a major problem, if Nordic wants to do it I see no reasons for not including this specific port in the distribution.

I'm not sure if this can be also applied to other systems, especially commercial systems, delivered as binary libraries.

salkinium commented 8 years ago

I'm not sure if this can be also applied to other systems, especially commercial systems, delivered as binary libraries.

Like the Bluetooth Softdevices from Nordic? 😜

ReinhardKeil commented 8 years ago

Thanks for pointing to that weakness. We will review and take action.

Note: For CMSIS-RTOS RTX a user timer can be defined, in cases where no SYSTICK timer is available.

jkrech commented 7 years ago

Please see the SVD documentation about the section here: http://arm-software.github.io/CMSIS_5/SVD/html/elem_cpu.html

In the SVD file you need to set the tag ``

... ... true ... ...

`` Please let me know if this fixes your problem.

jkrech commented 7 years ago

SVDConv Version 3.2.56 does not generate SysTick_IRQn anymore when true.

jkrech commented 7 years ago

Sorry for closing. David, please close if the problem is resolved to your satisfaction.

David-Garcia-Polo commented 7 years ago

Where can I ger v3.2.56? the one checked in is v3.2.53

jkrech commented 7 years ago

Version 3.2.56 should be the latest on the develop branch of the CMSIS_5 repo. What am I missing ? https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Utilities/Win32/SVDConv.exe

David-Garcia-Polo commented 7 years ago

It is me, I was taking master branch.