Skip to content
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.

activate JITTER #531

Open
nvkokorin opened this issue Dec 26, 2016 · 4 comments
Open

activate JITTER #531

nvkokorin opened this issue Dec 26, 2016 · 4 comments

Comments

@nvkokorin
Copy link

Hi everybody!
Some days ago I built it for the STM32F4DISCOVERY board. Cool! For speed testing I wrote little C# program there simply turn on and turn off the LED in infinity loop... And I got about 13 usec it's very slow!
So, I want activate JITTER but dot know how to do it. I tryed define TINYCLR_JITTER in the platform_selector.h but build with the MSBUILD ends with many errors. For ex.:
d:__NETMF\netmf-interpreter-dev\CLR\Include/TinyCLR_Runtime.h:3030:11: error: 'FLASH_SECTOR' does not name a type
const FLASH_SECTOR* m_jitter_firstSector;
and etc.

Could anyone help me to solve any way to activate jit. Thanks

@nvkokorin
Copy link
Author

nvkokorin commented Dec 28, 2016

Hi guys! After some nights I built netmf with JIT! But I got a some a little problem since )
In other words - now managed application not executed. I.e. VS2015 successfully loads my managed app to the board, jitter compiles it (writes thunk table and methods to the some flash sectors)... and all freezes.
What is the reason for this behaviour? Thanks

@smaillet-ms
Copy link
Member

This isn't likely to work. The Jitter code that is there hasn't been touched in over a decade. It only jitted to ARM mode (not thumb, which is required for Cortex-M devices). Further more the JIT requires RAM to put the JIT code into and most micro controller SoCs have a lot smaller RAM size then flash. This is the primary reason the JITTER was essentially abandoned in the past. For the overwhelming majority of devices it ended up running slower as the jitter had to keep re-generating the code as it didn't have enough room to keep much in a cache.

Toggling a single GPIO pin in this fashion is generally not recommended, as it hits the largest work load for the interpreter (Method calls) to achieve the smallest result (write a single bit). There's no single correct answer to this as it depends on what you are trying to do. For turning on an LED as a user indicator, the slower path is usually more than enough. For toggling GPIO as part of some sort of custom signaling to a peripheral (such as the Dallas 1-wire ) It is usually best to implement the bit toggling in native code and expose that via custom interop. (This is actually what the 1-wire implementation for NETMF does).

@weixiongmei
Copy link

Would you like to get together to work on the jitter?

weixiongmei@outlook.com

@weixiongmei
Copy link

weixiongmei commented Jan 30, 2017

The Jitter seems like can works on the ARM7TDMI processors....

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants