As per topic. I have very old machine that i cannot replace (some old railway machine). That machine still uses 3.5zip drive. I need to fit the USB instead. Therefore, as i`m completely not familiar with this system, can someone direct me please on where to start to reconfigure this ( if manageable of course) for use with USB? I guess there would a need for drivers etc so the USB is discoverable.
Thanks a lot in advance.
You'll need to download io-usb (the USB server) and Fsys.usb (the USB bulk storage driver).
Start here:
http://foundry27.com/sf/wiki/do/viewPage/projects.qnx4/wiki/InstallationNotesForUSBStack?selectedTab=versions&version=4
Continue here:
https://openqnx.com/phpbbforum/viewtopic.php?t=11230
Related
I've been working with a Micron BGA eMMC chip and prototyping a communication scheme with the eMMC chip inside an adapter board that connects to the GPIO pins of a TI microcontroller.
I've essentially created a communication scheme written in C code to walk through the initial handshake and initialization steps to get the eMMC to a Data Write/Read stage where I can write some small amounts of bytes to a part of the sector memory and read back the pattern I've written.
My next task is to format the eMMC into a partition format such as a FAT32 format, which is common among SD cards.
Does anyone know of any useful software or methods I could use to achieve this?
Or I've seen it's possible to format the eMMC using a Linux setup as well, but have little experience when it comes to Linux.
Any insight from anyone with past experience on the topic would be greatly appreciated!
If your system runs Linux that is the best option.
It is easy to format an eMMC using linux.
# mkfs -t fat32 /dev/mmcblk1
Is your TI microcontroller running Linux? If not, it might be diffiult connecting your BGA eMMC chip to a Linux system to format it.
Your second best option is to use a library that already supports it. Maybe something like (http://elm-chan.org/fsw/ff/00index_e.html) or (https://github.com/ryansturmer/thinfat32). There are several options I have not used any of them. To use these layers, you have to fulfill the lower level api.
I was looking for some Windows API that will give me notification for any change in the Local Area Connection Properties.I tried Searching for the Entry in the Registry which it modifies after we check or uncheck the driver name but could find it.
I have also attached an image if any one has any confusion in understanding my question.
Any guidance would be appreciated.
What you need is the Windows API for Network Awareness. It would be great if Delphi example implementations were readily available but they are not. The API's are all COM interfaces and you will have to find out how to use these within Delphi yourself. That is another question. However, for the INetworkConnection, this may get you started.
If I was told I needed to create a driver for some product (say, a game controller), how would I go about creating one? Is this something you could do normally in C/C++?
And what about firmware for external deviced connect to USB? How is this created usually? Is this also done in C/C++, or some lower level language?
Thanks!
Device drivers for desktop computer operating systems are generally written in either C or C++. The operating system you would target will have some form of framework or device driver development environment. Often these development kits can be obtained free of charge.
There are books available for Windows, Linux, and MacOS X (and others) that detail the process of creating a device driver.
If your driver is related to a device on a specific hardware bus (PCI, PCI-X, USB, SCSI, SATA, etc.) you can also get books on that specific technology. An understanding of that hardware system can greatly facilitate the design of your driver.
Another good resource is the open source code for similar devices to yours. You can obtain that from the Linux kernel source or FreeBSD source and study how certain aspects of your type of device are implemented.
EDIT: I nearly forgot to mention that you will also need data sheets, schematics, and/or theory of operation information about the device itself.
I'll add to Amardeep's good answer with the following books that will help you think about the context device drivers operate in, and how they're structured:
Linux:
http://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652
Windows:
http://www.amazon.com/Programming-Microsoft-Windows-Driver-Model/dp/0735618038/ref=sr_1_1?ie=UTF8&s=books&qid=1277439434&sr=1-1
Mac OS:
http://www.amazon.com/Mac-OS-Internals-Systems-Approach/dp/0321278542/ref=sr_1_1?ie=UTF8&s=books&qid=1277439467&sr=1-1
You do it in any language that can talk to the interface. If it requires poking ports or addresses directly then you use assembly or C. If there's a higher-level interface such as libusb then you can use almost any language you like.
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.