Is it possible for me to compile Haiku OS (a BeOS descendant) for mobile devices, for example, a phone? If yes, has anybody done it yet? Are there any examples?
At this stage it's not possible, unless you find a phone with an x86 chip in it of course ;)
There have been attempts to port the kernel to the ARM architecture and this would be the first stage in the process, devices such as the DS, some phones etc. use ARM chips. However I can't see it running on an ARM machine in the near future (read: 1-2 years) and even then there would be so many more things required - support for the phone features for instance.
For now all the effort is being spent getting it ready for the desktop, and rightfully so!
Related
I was curious about the ARM32 architecture (the 32-bit only version) and it's future: according to the wiki page, the Windows 8 variant Windows RT was ARM32, but it is deprecated now.
Windows 11 seems it will be ARM64-only.
What about devices released in-between?
I could not find any information/statistics related to this.
As far as I know ARM64 can run ARM (32-bit) applications, but one developing a system driver or working low-level has to support both platforms.
For comparison as far as I know, majority of current android phones are 64-bit already and with the 32-bit architecture having the 4GB limitation, logic would dictate, that outside of niche scenarios we should not really see 32bit-only ARM systems.
Anyone has any information regarding this?
There is absolutely no reason for MS to release ARM32 version:
No chip vendor is launching high end ARM32 chips
aarch64 is vastly superior to aarch32 while not much more expensive for licensees (if at all)
aarch64 is NOT backward compatible.
Why would MS want to fragment their Windows eco system more than necessary?
I am experiencing lot of troubles detecting BLE devices with a CSR8510 chipset. I don't have much knowledge in bluetooth hardware/stack and osx systems. I made a lot of research to solve my problem but I can't find any information specifically related to my issue.
Here is all the informations about my setup :
The dongle is plugged in a Macbook Pro late 2011 (mavericks). I made all the necessary to make the dongle work :
HCI bootmode
com.apple.bluetooth.plist deletion and reboot
I used Bluetooth Explorer to change the Host Controller (default internal chipset -> CSR8510)
Now the dongle is fully recognized by the system, I can use my Magic Mouse (all functionalities work), but I am not able to detect my BLE chest belt (Runalizer blue).
When I launch a scan with the Device>Low Energy Devices panel in Bluetooth Explorer or the demo app indicated by the belt manufacturer I don't find anything.
Demo app : https://developer.apple.com/library/mac/samplecode/HeartRateMonitor/Introduction/Intro.html
To be fully exhaustive my Xperia SP works perfectly with the belt.
I tried to dig into kernel extensions and I've found in System/Library/IOBluetoothFamily.kext/PlugIns two interesting kext :
CSRBluetoothHostControllerUSBTransport.kextCSRHIDTransitionDriver
I do not know if it is relevant or if it could help me but since they start by "CSR" I thaught that it may be related.
I hope someone can help me. It is bothering me so much because I am not able to do the job I was willing to do (gather data from the belt and statistical processing).
Thanks for your attention.
I have been long interested to develop on the platform. I even got the tools installed already on my desktop but I can't upgrade my WDDM from 1.0 to 1.1. To make things simple: my graphics chips are not up to the task of running the emulator.
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator?
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator
Yes, of course. It's very easy and convenient. You have debugger and all the goodies. Advantage of the emulator is the test option for 256MB devices.
That's exactly what I used to do prior to upgrading my devstation. The nominal min spec says 3G but with a real phone it worked fine in 2G and as you say this also sorts out graphics limitations.
Note that the setting for whether the emulator or physical device is used is stored in the project, so if you accept a project from someone else you will have to set it once prior to debugging.
Well there are 2 sides of the coin. With the physical device you can test most of the things, but with a few limitations
You will not be able to test internet related test cases - For example, if you have an app which uses internet connectivity then you will not be able to test it on the device easily because
The device does not use the machine internet connectivity
When connected to the PC the device's internet connectivity(Data connection 3G/ wifi/GPRS) is broken.
You will have to purchase an account right from the first day you want to test your app. If you have the emulator working then you could postpone this for atleast few days.
I have never worked with Siemens' SIMATIC industrial automation system, but I need to do following:
We have an industrial computer with Windows CE (for example an x86 Siemens TP700 comfort).
Is there a way to create a .NET application that would be able to work with SIMATIC ET200?
Or do I always need "SIMATIC NET" or Step7? I was told that SIMATIC NET does not work on Windows CE. Or can I use some OPC server that does not require SIMATIC NET?
Or is it impossible to use SIMATIC modules under Windows CE? It could be conclusion as well.
Try to lauch \Windows\cgacutil.exe on your CE platform. If it is there, it will tell you the version of the '.Net compact' framework. If there is one installed, you can write applications targeting that particular version. The '.Net compact' is only a subset of the full .Net on desktops.
Hmm, first of all which ET200 fieldbus device want to work with?
Generally you must have ET200 with ethernet (ProFiNet - process field network) interface, than at least you don't have an IM151-7 (or 151-8) that are a CPU as first unit in ET200 rack you need other software to make you pc as a master profinet device, the slave device are basically stupid devices as long as initialized by a master device, that usually is the CPU.
Second thing: the TP700 is a WinCE Panel,with basic function that need to programmed into HMI software designer (WinCC for TIA Portal) and has a very limited resources.
My point of view: first you need to explain what need to do: a S7-1200 CPU even the most basic model do everything you want: address the ET200 rack, read and write the I/O data and collect them ready to be read or write from TP700: you need half day for all job, most time is need to do the graphic interface.
The other solution could be put a linux CPU (raspberry or everything else) that the necessary tasks to address ET200, read and write data to it, process the data and place them readable from TP700 (programmed with WinCC)
I'm programming automation devices from 27 years (I'm 46 year old) and I've basic knowledge of pc programming: from my point of view you get best result, reusable code, less time, less heachache with a plc cpu instead of pc code.
I'm building an IOKit CFPlugin driver for OS X. I'll be working with network data coming in that will be translated to MIDI data. No hardware is involved other than the built-in Airport. I have experience with drivers on Windows machines and firmware but this is my first dip into doing it on the Mac. So far things are going pretty well, but the Apple documentation sez: "For safety reasons, you should not load your driver on your development machine."
I only have one Mac. I really don't want two Macs- sorry, Apple. Should I take this warning seriously? Are there things I need to know?
Thanks, Tom Jeffries
You could also consider running OS X inside a VM as your testbed. It would surely be much more convenient that having a separate boot volume.
The warning is rather poorly worded; what you should consider doing is using a separate boot volume (partition) for trying out your driver, since it's possible to arbitrarily hose your system with your driver.
If you're doing kernel development on any OS that isn't isolated from your main system (via a VM, alternate boot disk, etc.), you're crazy!
What may be a bigger issue is that you can't do any kernel debugging, because the only option for that is to use GDB on a remote OS X system. For this, you may want to consider running OS X in virtualization.
you DEFINITELY want to have some way to recover a fubar kext installation: a bootable external drive or something you can quickly restore from-- this is the main reason for Apple's warning against running in-development-kernel-extensions on your production machine.
Nicholas is right that in order to debug using gdb (the only way in kernel space) you do need two machines. I've never tried using a VM as Coxy suggests: but I guess it's feasible (assuming that you run your kext on the virtual machine and use the real host machine to run gdb).
My preferred method for tracing and debugging in the kernel is kprintf() routed to firewire (aka firewire kprintf (man fwkpfv) ). for this you do need two machines with firewire ports.
finally, being an old computer musician myself, I wonder why you want to program a MIDI synthesizer (or transformer) on the network stack level. my guess is that you would have a much more gratifying experience working in userland (where you can use floating point math...)
if you need some hints or tips, feel free to get in touch...
|K<
from the ADC Kernel Programming Guide
Kernel programming is a black art that
should be avoided if at all possible.
Fortunately, kernel programming is
usually unnecessary. You can write
most software entirely in user space.
Even most device drivers (FireWire and
USB, for example) can be written as
applications, rather than as kernel
code. A few low-level drivers must be
resident in the kernel's address
space, however, and this document
might be marginally useful if you are
writing drivers that fall into this
category.