I'm trying to figure out what I'm doing wrong: Using Microsoft's Device Emulator 3.0 with one of the included WM6.5 runs fine and feels quite responsive, even when debugging own (.net-)applications.
But if I try an own custom image, the user interface inside the emulator is extremely unresponsive and sometimes it takes two seconds for WinCE to register a simple click on a UI button.
There are no informative kernel debug prints...
Details:
Platform Builder for WinCE6R2
ARMV5 Emulation target
Industrial control template with minimal options
Release build
Emulator options: 128MB RAM, NE2000 emulation, 480x272x16 video settings
Is there anything I can take a look at to further troubleshoot this issue?
If you need to debug just applications you can build an image using the Virtual PC BSP. It provides better performances than the ARM emulator. You can connect using TCP/IP and even copy data files by mounting the VHD file in your machine if you have a Windows 7/8 PC.
Related
I have a vulkan application I want to profile (to find the bottlenecks on the gpu for optimizations). I am on linux and amd hardware so I downloaded the linux version of the radeon developer tools. I ran it and created a local server and that seems to work.
I then launched my program, but it does not appear on the list of profiling candidates in the panel.
As you can see the connection is fine (green dot), but no applications are detected. I have tried with advanced mode as well but no luck.
I know for a fact the program is running as I can see it and use it, recompile it... Has anyone run into this problem before?
I'm trying to develop for HoloLens but my laptop doesn't support the needed specs, so I was trying to figure out a virtualized solution (namely, using an Azure VM).
After unsuccessfully running the emulator on the Azure VM, I found that according to Microsoft (https://technet.microsoft.com/en-gb/library/hh831531), "The Hyper-V role is not supported on a Microsoft Azure virtual machine", which kills that idea.
Does anyone know of an alternative virtual option for developing and running the HoloLens emulator, which doesn't rely on the host machine's (i.e. my laptop) specs?
Yes, in the latest version of Unity which is Unity 5.5, there's a new feature called "Holographic Emulation" that will enable you to run on a simulated device directly in the editor.
As for the requirements, you need to have
Unity 5.5 installed in your machine
Windows 10 Anniversary Update (or later) installed
Here's the link to the blog in case you want to check more details about the simulator
Hololens emulator IS the Hyper-V virtual machine with Windows 10 and 3D graphic capabilities. The host machine should be able to run Hyper-V (CPU/BIOS limitation) and have a 3D adapter. More details are here:
https://learn.microsoft.com/en-us/windows/mixed-reality/using-the-hololens-emulator
Then you could install the emulator from
https://learn.microsoft.com/en-us/windows/mixed-reality/install-the-tools
Hololens emulator is not supported in VM due to CPU limitation, you can use holographic simulation in Unity instead.
I'm attempting to profile a remote process to look at thread and memory diagnostics. When I attempt to attach to the process via Debug, everything works swimmingly. However, when I try to attach through Analyze (for profiling) I cannot find it. Is this functionality not supported at this time?
You can install Windows ADK on remote machine and use Windows Performance Recorder and Windows Performance Analyzer to do some Performance Profiling.
All, Forgive me I am the beginner of the WDK development, I was reading some tutorial from msdn in here
and the read says
Typically when you test and debug a driver, the debugger and driver
run on separate computers. The computer that runs the debugger is
called the host computer, and the computer that runs the driver is
called the target computer. The target computer is also called the
test computer.
So I was wondering if the host computer and target computer can be the same one ? thanks.
There is a possibility for live debugging in Windows Kernel debugger. Not all the commands of the debugger will be available (http://msdn.microsoft.com/en-us/library/windows/hardware/ff553382(v=vs.85).aspx).
Another option is to use two virtual machines and redirect the serial ports of those VMs through named pipe or TCP\IP. If you are just beginning and mostly playing with Toaster sample driver - this is more than enough.
It is always advicable to have a host pc and test pc seperate as
when you a developing a device driver you might end up crashing the system multiple times which might lead to hard disk failure and hence if host pc is same as test pc, you would lose all your data.
I'm looking for a really really small linux distribution or process of making my own that's sole purpose is to get an air application to launch full screen and stay there; Essentially I'm building a home kitchen computer that runs entirely as an AIR app.
I have looked into using windows xp; and windows xp embedded but they pose so many issues I figured I'd try modern linux.
I have also seen TinyCore Linux which looks interestingly small but not sure what issues that poses in regards to running AIR and "hardware" accelerated display. I've also thought about stripping down an Ubuntu installation but I'm sure somebody must have done this already; google is just failing me right now...
I'm also interested in running an "embedded" version of say android and running the air app on some arm-based hardware again; with just the AIR runtimes only - although this is less preferred as it's more complex.
I'm also hooking this up to a touch screen monitor (not yet arrived) so I'll need to hunt down or write some drivers for translating the touch events into something AIR can understand... (this was my main intention for using windows in that all the drivers will just work).
What I'm after
Minified Linux kernel with JUST the drivers for the box I need
X Display with accelerated graphics support (Doesn't have to be X if AIR can run on a frame buffer?)
Running a Full screen AIR application (simple enough)
Ability to write back to the filesystem (enough support for AIR)
SSH Access for remote control
Samba for updating the filesystem (easier to maintain the system)
Touch screen support (3M Ex III I think...)
Audio support
Don't need
Don't need any window manager or any other GUI tools unless required by AIR
Don't need any toolbars or file managers or anything; The AIR app is the "OS"
Don't need any package managers or repos
Don't need multi user or logging in; everything can just run as an unprivileged account
Don't need to
I don't mind hand crafting the filesystem and configs if that makes it easier; I'm mainly looking for a "filesystem" that is as tiny as possible that I can just plop my AIR app into and write some scripts to get it to start when the X server starts
Thanks,
Chris
Try an embedded Linux build system such as Buildroot. It can build an entire system from source, and be very lightweight. The basic system is less than 1 MB in size.
Ended up going with Tiny Core. Very tiny and quick to boot up. You can also write extensions for it and you don't have a persistent drive which allows you to just switch the thing off without worry that it's going to break something -- exactly what you need in a kitchen :-D.
My current plan is to:
Just set up a working version using Ubuntu as this is mostly supported by Adobe
Slowly strip it back and try and get as little things to start as possible on boot
Try building my own distro/package from source and selecting only the packages I need
Compile my own kernel with nearly everything turned off and just leave on the things I need