I am new to freeRTOS and would like to modify the OS to accommodate some new hardware. I would like to do this in an emulator, which could be either Windows or Linux (preferred).
I have installed and operated freeRTOS in both systems and it all works. I want to tweak some of the freeRTOS internals, rebuild the emulated freeRTOS, and test the result.
I am looking for some direction and hints on the best way to go about this task.
Such a massively open ended question with no indication of what it is you want to achieve makes this unanswerable. There is some info on how the Windows simulator/emulator/port works here http://www.freertos.org/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.html
Related
I am trying to understand the inner workings of XCode's Instruments. On MacOS, it can rely on DTrace to gather all kinds of profiling data. On iOS, it is also capable of lots of things, but I have read repeatedly that DTrace has not been ported to iOS.
So how does that work?
The Apple documentation on DTrace isn't telling me much about the inner workings here. I have noticed, however, that when profiling my own App from XCode using Instruments, XCode seems to build it differently. Could that mean it links some standalone DTrace providers with my code?
Thanks in advance!
/e: I would bounty this question with my ENTIRE 6 REPUTATION POINTS if only i could...
For iOS apps running inside the Simulator, obviously the Simulator is a Mac OS X program, so it can use DTrace to monitor everything the Simulator does.
For iOS apps running on an iPhone, I agree the documentation provides little insight into what's happening. It's probably either loading monitoring code into the target process on iOS (either by adding the code at compile time or by linking it in at runtime) or there is an "traditional debugger" running on iOS against the target process to implement the tracing. Those are pretty much the only options if there is no kernel-level support for using DTrace.
I've never used Instruments, but the main thing that jumps out at me is that they're able to collect seemingly-OS-level statistics about I/O, which would not normally be measurable without DTrace. I'm not sure because I haven't used it, but it's possible these statistics are only tracking I/O from easy-to-detect entrypoints (ie I/O-related syscalls from the specific target process), or that there are other iOS-specific statistic sources which are published by the OS. For instance, many system statistics can be gotten from Mac OS X by calling sysctl. Depending on what statistics are actually being collected, Instruments could just be using simple counters like these to do most of the work.
If you're really determined to find the answer, it would be a fun DTrace challenge to figure this problem out by DTracing Instruments itself. Good luck :-)
I want to port a good OpenCV code on an embedded platform. Earlier such stuffs were very difficult to perform but now TI has come up with nice embedded platforms which are comparatively hassle free as they say.
I want to know following things:
Given that :
The OpenCV code is already running on PC smoothly. (obviously)
Need to determine these before purchasing the device.
Can't put the code here in stackoverflow. :P
To chose from Texas Instruments: C6000.
Questions:
How to make it sure that the porting will be done?
What steps to be taken to make it sure that after porting the code, will run (at least).
to determine whether the code might require some changes to make its run smooth.
The point 3 above is optional.
I need info which will at least give me some start up in this regard.
What I thought I should do?
I am to list the inbuilt functions down.
Then to find available online bench marking for those functions for the particular device like as shown towards the end of this doc.
...
Need to know how to proceed further?
However C6-Integra™ DSP+ARM Processor seems the best.
The best you can do is to try a device simulator (if it is available), but what you'll see there is far from perfect.
Actually, nothing can tell you how fast and how well the app will run on the embedded device before running you specific app on that specific device.
So:
Step 1 Buy it
Step 2 Try it
Things to consider:
embedded CPU architecture: Your app needs a big cache? how big is the embedded cache?
algorithm: do you use a lot of floating point operations? how good is the device at floating point ops?
do you have memory transfers? data bus on a PC is waaay faster than on embedded
hardware support: do you use a lot of double-precision calculations? they are emulated on ARMs. They are gonna kill your app (from millisecons on a PC it can go to seconds on a ARM)
Acceleration. Do your functions use SSE? (many OpenCV funcs are SSEd, even if you don't know). Do you have the NEON counterpart? (OpenCV does not have much support for that). The difference can be orders of magnitude from x86 SSE to embedded without NEON.
and many, many others.
So, again: no one can tell you how it will work. Just the combination between the specific app and the real device tells the truth.
even a run on a similar device is not relevant. It can run smoothly on a given processor, and with another, with similar freq or listed memory, it will slow down too much
This is an interesting question but run is a very generic word in this context, therefore I feel the need to break it down to other 2 questions:
Will it compile in an embedded device?
Will it run as fast/smooth as in a PC?
I've used OpenCV in a lot of different devices, including ARM, SH4, MIPS and I found out that sometimes the manufacturer of the device itself provides a compiled version of OpenCV (for my surprise), which is great. That's something you can look into, maybe the manufacturer of your device provide OpenCV binaries.
There's no way to know for sure how smooth your OpenCV application will be on the target device unless you are able to find some benchmark of OpenCV running in there. PCs have far better processing power than embedded devices, so you can expect less performance from the target device.
There are 3rd party applications like opencv-performance, that you can use to test/benchmark the environment once you get your hands on it. And if performance is such a big deal in this project, you might also be interested in this nice article which explain some timing tests done on couple of OpenCV features comparing implementations using the C and C++ interfaces of OpenCV.
I recently started to learn how to use openCL to speed up some part of my code. So far the speed gain is impressive. In one case the code ran up to 50X faster than on the CPU. However I wonder if can start using this code in a production environnement. The reason is that the first time that I tried to run the example code, nothing worked. I was able to make it run by downloading the driver on the Nvidia openCL SDK download page (I have a Geforce GTX260). It gave me a blue during installation but after that I was able to run the example program and create my own code.
Does the fact that it didn't work "out of the box" for me mean that the mainstream drivers does not yet support it, despite the fact that it is specifically written that it does on the driver download page? What about ATI support? Will everyone have to download the special driver that gave me a blue screen on install?
In short, is openCL ready for production code?
If someone can give me some details, I'd like to know. Does anyone has been able to run a simple program on a number of different device without installing anything SDK related?
You may find an accurate answer on the OpenCL forums on the Khronos Group message boards. The OpenCL work group hangs out there regularly.
Does anyone has been able to run a
simple program on a number of
different device without installing
anything SDK related?
Nop. For instance, on ATI's GPUs end-users need to install ATI Stream SDK in order to run OpenCL code (just having an up-to-date graphics driver is not sufficient).
You may want to consider trying DirectCompute (Microsoft's version of GPU programming) or doing your OpenCL work on a Snow Leopard Mac. Those are the two ways (that I know of) that you can deliver a GPU programming solution to another user without any driver or other installation hassle.
Is there an official way for an application to determine if it is running in VMWare or Virtual PC (or whatever Microsoft is calling it now)? The code I have seen is usually a hack that took advantage of some odd behavioral side effect in a specific version of VMWare or Virtual PC.
Ideally Delphi code, but if you can link to an official explanation then I am sure I can convert it.
I wrote a series of articles last year on this, with source code. VMware and Wine detection are here. Virtual PC is here. All three of these have pretty iron-clad detection because there are documented callbacks to the hypervisor (in the case of Wine, an extension to a standard DLL). I put up an untested VirtualBox detector (don't have it installed to test with) in the comment section. Parallels might be detectable using a callback also but I don't have it installed. The link for the documentation (which is poor since it's from a security researcher focusing on exploits) but located here if you have it installed and are interested. There's also a PPT here that has some information on detecting Sandbox, Bochs, and Xen. Not a lot of code in it but it might give you a starting point if you have to detect those.
Code Project shows a way to Detect if your program is running inside a Virtual Machine that goes in much detail on how to accomplish it to give a good understanding
I think the best approach to this is to check the hardware profiles. Virtualized hardware usually uses part of the companies name. If you check the motherboard description while in Virtual PC, you will notice it is made by "Microsoft Corporation". Likewise in VMWare, your ethernet adapter will be prefixed with VMNet.
This thread on the SysInternals forums has a couple of answers (in Delphi, of course), including a single IsVM function. I've tested on XP and Win2003 hosted on both XP and Vista in VMWare with good results.
There is a WMI way posted here:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/27/484479.aspx
I've double checked in an XP image running on Virtual PC, and the value they're testing for is still the same. I won't guarantee what other VMs return here, though...
I've actually got a Delphi program I wrote a couple of years ago to get a list of and change the default printer using WMI, without requiring 3rd party components or anything like that. In case you're not used to working with WMI from Delphi, I can send you a copy so you have something to work off (it's not necessarily Unicode-compatible, though, but it shouldn't be too hard for me to upgrade it if need be).
I used the RedPill method (translated to Delphi, but the code isn't that hard to understand) which worked fairly well. I also included a few extra checks using WMI calls to get things like the network adapter vendor name and copyrights, but that was for detecting specific versions of Virtual PC.
My understanding of the RedPill method is that it should work and detect all virtual machines based on the nature of how it works. There is the possiblity that false positives might be generated also as the new Windows within Windows feature of Windows 7 can be configured to run selected programs in a copy of Windows XP seamlessly inside Windows 7.
I've had good luck with just looking at the MAC address as all manufacturers are given a block and the first 3 parts are unique to them.
//look at the MAC address and determine if it's a Virtual Machine
$temp = preg_split("/\s+/",exec("/sbin/ifconfig -a eth0 2>&1 | /bin/grep HWaddr"), -1, PREG_SPLIT_NO_EMPTY);
//Virtual Box MACs all start with '08:00:27:xx:xx:xx'
if (strpos($temp[4], '08:00:27') !== false) $_SESSION['DEVELOPMENT'] = true;
To determine the machine is physical or VM
dmidecode | egrep -i 'manufacturer|product'
If the dmidecode command not found install the respective rpm.
This is tested under EXSI, VMWARE and hyperv machines.
dmidecode -s system-product-name
Tested on VirtualBox, result:
Virtualbox
If you want to generally detect the presence of any type of virtualization, you are best analyzing performance characteristics. Take something that is significantly slower in virtualization (such as MMU heavy workload like a fork-bomb) and time it against a normal CPU bound user space app. From the ratio you can easily tell.
Easiest in terms of effort if you only care about certain VMMs is to look for their hardware- i.e. VMware PCI devices:
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
Subsystem: VMware Inc Virtual Machine Chipset
15ad:1976
The vendor value is '15ad'
There are also specific backdoor ports that work across various VMMs in various versions. SIDT trick is good too, but what if a VMM is not on the list that his code is checking?
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.