• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 102 subscribers
  • Views 2592 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How real is Win32 support?

Beat Arnet3421
Prodigy 70 points
Other Parts Discussed in Thread: SYSBIOS

Hello Community,

I am very interested in running SYS/BIOS on a Windows PC for unit-testing of threaded RTSC modules.

After some struggles, I have been able to build 6.32.05.54 for the microsoft.targets.Win32 target, and I also successfully ran a test using a Timer as well as one Task.

However, when I moved on to using a Semaphore, exactlly as demonstrated in the CCS sample project, I ran into the following exception, which is thrown during the context switch after posting the semaphore:

ti.sysbios.knl.Task: line 340: E_spOutOfBounds: Task 0x40c220 stack error, SP = 0x344b98.

xdc.runtime.Error.raise: terminating execution

This could very well be operator error on my side, but considering the fact that the SYS/BIOS distribution does not include compiled Win32 libraries, and considering how little documentation exists about running SYS/BIOS on a Windows machine, and considering that VC++2010 is not supported, I am wondering if am asking something from SYS/BIOS for which it is no longer fit.

Therefore my question to this forum: Is anybody successfully running SYS/BIOS on Windows? If so, are there any specific gotchas that a user like me needs to be aware of?

Thank you,

Beat

 

 

 

 

 

  • 0
    TI__Guru* 96960 points

    Looks like you exceeded your stack for one of your Tasks. Try increasing it.

    SYS/BIOS on Win32 was supported at one time. Due to lack of customer demand, we have not actively validated that we did not break something. We are dropping support in future releases on SYS/BIOS.

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 70 points

    Hi Todd,

    Unfortunately, increasing the stackSize makes no difference (went all the way to 100,000).

    Thanks for shedding some light on the plans with regards to Win32. Personally, I wish TI would still support it, but I understand and appreciate that this requires a serious commitment, which is hard to justify for only a few of us.

    How about support for Linux x86 instead?

    Regards,

    Beat

     

  • 0 in reply to Beat Arnet3421
    TI__Guru* 96960 points

    Linux support is even more bleak. We did some initial work on this a couple years ago and hit a couple issues. It's been on the back-burner since then.

    Todd

  • 0 in reply to ToddMullanix
    Expert 1255 points

    I wanted something similar, as we have a Win32 multi-threaded "proof of concept" application written when we still thinking of a non-TI target device with a more POSIX OS.  We're possibly trying to port it to a C6678.  I looked at the ti.sysbios.family.windows stuff as a porting pathway and concluded that it wasn't up to the job.

    Here's some notes on what I have got working, in case they're useful:

    • I downloaded OSAL, which at least implements xdc.runtime.knl proxies for Linux, and managed to adapt those for Win32.  So I now have a working OSAL/Win32 that can do xdc.runtime.knl.Thread.create(), use xdc.runtime.knl.GateThread, etc. There was a certain amount of faffage involved but this was probably only 1-2 weeks work and seems to be fine.  As a side benefit, you can use xdc.runtime.Log under Win32 which actually seems quite a nice logging solution.  Since SYSBIOS has proxies for all of these as well, I hope that this code will "just work" on the target.  Haven't actually tried properly yet as the project is on pause again.
    • I got IPC building against my OSAL/Win32 so I could use MessageQ.  This is a bit rough and ready, and was much harder than I had hoped.  There are a lot of BIOS bits buried in IPC: it uses ti.sysbios.Cache rather than xdc.runtime.knl.Cache (which have different API signatures) and I had do a lot of this:

    #define Hwi_disable Gate_enterSystem
    #define Hwi_restore Gate_leaveSystem

    It does seem to work, in that I can create threads (via xdc.runtime) and send messages between them.  That will do for me for now. 

    • I didn't find a sensible option to implement Timers, SWIs or ti.ipc.Notify, as far as I can see.  The ti.sysbios.family.windows does manage by using SuspendThread, which is essentially a debugging API.  While ingenious, it doesn't really fit with any other use of Windows threads or synchronisation, nor can it easily be made multi-core.  It seemed designed for fidelity rather than performance, eg. it appeared to create a thread for each HWI rather than pooling (but I might be wrong about that).

    I do need timers, but will live with having separate Win32 and TI code for those.

    • I had a look at syslink, but it isn't really a "HLOS" implementation of IPC as I would define it.  It depends on Linux kernel extensions to embedded Linux and has a build system which is very hard to add targets to.
    • One could build a true multi-core model with a set of processes (with private memory and the ti.sysbios.family.windows scheduler) and some shared memory and Windows IPC to do inter-core comms, but that's a big job.

    In summary we certainly would have made more use of Windows support if it were in a better state: not just BIOS, but also IPC and the NDK.

    Also, let's talk about RTSC on Win32.  Overall, I like RTSC, very much.  However on Win32 there are a lot of little annoyances and niggles, especially with microsoft.targets.Win32 as opposed to MinGW - I've reported 2 minor bugs already.  (Our proof-of-concept was written in Visual Studio 2008, and I don't want to change toolchain at this point). 

    Just one example, you need to find out the "short path" to the Windows SDK directory for your include files, as the build tools can't cope with spaces in filenames.  But short paths "don't exist" for Java so this is very difficult to do inside XS.  Result: it's very hard to have a Subversion checkout that "just works" on different machines without setting lots of environment variables either manually or using an entirely different method (I use WSH/JScript).

    The fact that "out of the box" only compilers up to VS2005 are registered says quite a lot by itself.

    One of the most annoying was the alignment - for reasons that aren't apparent, microsoft.targets.Win32 insists on compiling with /Zp1 (struct alignment of 1) at a very low level that can't be overridden at runtime.  I had to create my own target, hacked from the XDC one, and edit the generated .java file (as I could not work out how to rebuild the package!) and rebuild the xdc.runtime package to match.  /Zp1 creates random crashes if you want to use the Win32 API and could cause odd things to happen with misaligned floats.  I really can't see why that was done, because lots of the TI targets have alignment rules stricter than Win32 does... 

    I'm happy enough with where I've got to, but if I'd known how much time (cost!) it would take to get here I would have done things quite differently.

  • 0 in reply to Gordon Deane
    Prodigy 70 points

    Thank you for your reply, Gorden.

    This information is extremely useful and I much appreciate you taking the time to write it all down!

    Beat

  • 0 in reply to Beat Arnet3421
    Prodigy 70 points

    Todd,

    What about official Win32 proxies for xdc.runtime.knl in OSAL, as Gordon developed?

    This sounds like a very valuable improvement for a future version of OSAL.

    Beat

  • 0 in reply to Beat Arnet3421
    TI__Genius 17205 points

    This is a great idea.  I manage the OSAL product, so have some say in it...  :)  Gordon, any way we could get a hold of those Win32 delegates, align on a BSD license and include them in a future OSAL release?

    Chris

  • 0 in reply to Chris Ring
    Expert 1255 points

    Chris,

    As I'm a consultant, whatever IP I produce belongs to the client.  While I'm personally a big fan of Open Source, I don't think that's going to be an option with this client.

    Also I wouldn't want to raise expectations.  I didn't implement all the proxies properly, just the ones I needed, and it was a very quick-and-dirty job as this is not going to be part of the final product.

    I think I can give a few further notes about what I did, in case it's useful.  The proxies needed for xdc.runtime.knl were:

    • Cache: nothing to do, use xdc.runtime.knl.CacheSupportNull
    • GateThread:  Wrapper around a Win32 CRITICAL_SECTION based on http://rtsc.eclipse.org/docs-tip/Extending_xdc.runtime_Gates/Example_1 instead of pthread_mutex.  CRITICAL_SECTION is the fastest synchronisation primitive if you don't need inter-process sync.
    • GateProcess:  Similar wrapper around Win32 kernel mutexes (CreateMutex(), etc. ) though to be useful this would need a SharedRegion implementation wrapping Win32 SHM to share these with other processes, and I didn't get that far.
    • SemThread/SemProcess - wrappers around CreateSemaphore().  Win32 semaphores can be used inter- or intra-process, and either binary or counting as you wish.
    • ThreadSupport - this is based on the OSAL version, mostly this is just CreateThread(), join uses WaitforSingleObject(), and I didn't do all the priority stuff.  One useful trick was that you can get a Thread Local Storage (TLS) "index" key in module initialisation, and then stuff the ThreadSupport_Handle into the associated thread-local cubbyhole with TlsSetValue().  This gives a natural way to implement ThreadSupport_self as TlsGetValue() and also an easy way to get the thread name if you've enabled those.  Also there's a trick to set the thread name for the Visual Studio debugger - search for SetThreadName in MSDN.
    • There's a bit of a "mismatch of model" with thread priorities: in Win32, your process priority determines your "band" within the scheduler, and thread priorities are just a "fine tuning" knob within that band.  You can't really have a "realtime" thread and a true "idle" thread in the same app with some other process getting scheduled at a priority in between.  Also the scheduler won't do strict priority preemption in the way BIOS or other RTOS would.  So the thread priority is not that useful a concept on Win32 IMHO.
    • System.common$.gate as a GateThread (CRITICAL_SECTION) instance.
    • LoggerFlex (from OSAL) was quite useful, although you need to change the thread IDs to use either Windows IDs or (more usefully for me) the thread name.

    The IPC module requires

    • GateMPSupport - the semantics are slightly different, and I was not quite sure how to bring the model across to Win32. 

    My Ideal Solution

    (Which I don't have time or need to write just now). 

    What would be great would be to have an easy ability to launch a set of different processes for different "cores" to model the L2 RAM and separate task schedulers on a multicore device, with shared memory representing common RAM, including memory for inter-process gates.  This would want:

    • A "SharedRegion" implementation to share inter-process gates
    • A version of IPC that "just works" with inter-process NameServer
    • A "JobObject" to indicate that the processes should all be managed together.
    • A choice between using the Win32 scheduler (for high performance and use of multiple x64 cores), eg. for mathematical worker tasks OR an improved version of the ti.sysbios.family.Windows offering a "more faithful" scheduler with Timer objects etc.  in order to simulate a master core with more complex activities and synchronisation requirements.

    Probably this is all too over-the-top when you already have device simulators to prototype on. 

    Unit Testing

    The other important use case for a Win32 xdc.runtime.* is to be able to compile, run, and debug unit tests.  This is especially true where the simulators are bulky and complex (ie. the C6678) and less useful where there's a lightweight simulator as for the Kelvin devices.  In that case, working schedulers and threads etc. are not that important, but being able to use sensible "mock" objects potentially is.

    Sorry I can't offer you any code, though.

    - Gordon

    PS.  You don't have a tag for OSAL in the pop-up tag list for this forum, perhaps you should add one :-)