search

NETMF / netmf-interpreter

.NET Micro Framework Interpreter
http://netmf.github.io/netmf-interpreter/
Other
487 stars 223 forks source link

Where to start to port netmf on new OS? #375

Open Bsvt opened 8 years ago

Bsvt commented 8 years ago

I am trying to add one more OS on NETMF. But I don't know where to start. Is there any document in this regard? Where are the exception handlers in NETMF?

smaillet-ms commented 8 years ago

Which OS are you interested in porting to? Generally speaking NETMF doesn't deal directly with processor exceptions, that's entirely in the HAL layers.

Bsvt commented 8 years ago

I am trying to port Nuttx. If I understand you correctly, PAL & CLR exception handlers are only thorough HAL, if so, in the architecture diagram, I see CLR dependent on CPU support, what are the CPU support it is dependent on?

I am new to ms project, & I couldn't exactly find these exception handlers even in HAL. (except hw related inits are done in HAL_initialize )

So where are the exception handler hooks?

smaillet-ms commented 8 years ago

Perhaps we should step back and identify what you mean when you say "Exception handler hooks". There are quite a few possible interpretations of what that could mean in the context of .NET + C++ on a micro controller.

In general since NETMF is an interpreter it doesn't really care about hardware based low level exceptions. so there's nothing to "hook" in that regard. Inside the HAL layer there is a set of functions that abstract the interrupt controller and provide a way to specify a function that is called when an interrupt occurs. Additional hardware exceptions like divide by zero or access violations etc... are entirely at the discretion of the HAL developer. NETMF itself doesn't require any of them.

Bsvt commented 8 years ago

Yes, I see a clear HAL definition & there isn't any dependency from CLR. I started looking into the RTX port for reference to start with. Nuttx has its own HAL layer, I need to route HW access through NETMF HAL layer instead of Nuttx HAL. Though it is doable, can somebody give a hint about how this is handled in RTX port? Is there any good document on RTX port on NETMF?

smaillet-ms commented 8 years ago

RTX is an implementation of the CMSIS-RTOS API and as such is just a thread scheduling kernel. It has no API definitions for any peripheral IO of any sort. Instead the rest of the CMSIS-DRIVER API is expected to fulfill that role. NETMF does not currently use CMSIS-DRIVER as it already had its own HAL API. Furthermore ARM had since introduced mBed and was in the process of building its next version of that. Thus there were a lot of things changing and not all compatible. Our hope is/was that mBed OS will standardize the device/HAL layers for Cortex-M across all of ARM's offerings so that everyone is working from a single API for the HAL and we can focus on what makes NETMF distinct and of value. (e.g. The more time we spend supporting multiple HAL APIs the less time we have for actually adding functionality to NETMF itself)

I find the biggest confusion in all of this is in the use of the term Operating System or even RTOS to describe the likes of RTX, Free-RTSO, MQX, etc... These are best thought of as thread scheduling kernels as, due to the awareness of the much larger Operating Systems (Windows, iOS, Linux, Android, etc...). Using the familiar systems as a reference it is all too easy to make assumptions about the RTOS that aren't even close to true.

For a port to another system like NUTTX you'd probably want to start at the PAL level and skip the NETMF HAL since NUTTX already has it's own HAL support.

Bsvt commented 8 years ago

"For a port to another system like NUTTX you'd probably want to start at the PAL level and skip the NETMF HAL since NUTTX already has it's own HAL support."

With Nuttx ported at PAL level & using its own HAL, whereas NETMF using its own HAL, these can't co-exist. I need to somehow route one thorough the other, right? otherwise, hardware ports would might get into out-of-sync when accessed by both.

doingnz commented 8 years ago

modify NETMF PAL to call NUTTX PAL might be an approach.

smaillet-ms commented 8 years ago

You wouldn't use the NETMF HAL, it's not a requirement. The HAL is an implementation detail of so called "bare-metal" platforms. (e.g. no OS of any sort). Due to the long history of systems built that way the existing solutions and ports leave one to believe that's the only way of doing things. However, the emulator, which is an instance of NETMF running on top of Windows, stands as a reference to demonstrate otherwise. When initially brining up the new network stack we had a build of NETMF for Win32 with the LWIP stack (using a custom driver with WinPCap as the Ethernet controller). We couldn't get to include SSL there because of too many compilation issues of OpenSSL on windows (it has a number of preprocessor tests for things like WIN32 and MSCVER that trigger an assumption of building on windows so it pulls in Windows network stack headers that conflict with LWIP headers.) I'll see about pulling that back out of the version control system we used before shifting to the public facing GitHub for all active development. That could also serve as a rapid build/test platform for integrating the mBed TLS support to replace the Crypto libs and OpenSSL.