Porting Windows demo apps to WinCE/XP Embedded - delphi

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.

Related

Tiny WiFi connected relay - where to start

I'm trying to get some initial info on my very first IoT project. I want to build a * tiny * wifi connected relay to control, let's say, lights. I'm a newbie in the hardware and electronics field though, but I'm a pro developer, so programming is not a problem.
Now, I've looked at different options and I can't seem to find really small components for the task. It might be I overlooked something, so please help me with available options.
Look at the ESP8266 devices. They have WiFi on chip and can be programmed using the Arduino environment. You basically write code in C++ to do whatever you need.
Here is an Amazon search for some examples:
https://www.amazon.com/s?k=esp8266
I recently did a project using a Linknode R4 (similar to above but with 4 relays) and programmed it as a web server with REST API. Then I built a front end with ASP.NET Core to that talks to the REST API for the devices on my network. The Arduino sketch for the web server is posted on Github at https://github.com/SteveInCO/LinknodeR4. I would assume it would work with little modification on the device I linked above.
The default program for the R4 allows controlling it via their website or iOS/Android apps, though I could never get it to work out of the box. Their model uses a polling method so the relays continually ask the server what to do next.
Windows IoT doesn't run on these small devices yet, but no reason you can't front end the Arduino API with a UWP app running under Windows IoT on a Raspberry Pi instead of the web app like I did. I think the eventual plan is for ASP.NET Core to be able to run on an ARM based system like a Raspberry Pi, but last I checked it wasn't quite there yet.

Possible to create a zeroconf service with Delphi XE5?

Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.

What does a device driver look like?

When a manufacturer designs a hardware device, they obviously have someone who is in charge of writing a driver for that device for different platforms.
While I know that there are probably more than one "type" of driver for different types of devices, a driver for a device by it's nature must be very different from a normal application or script.
I've always wanted to pick apart a driver just to find out how it allows an OS to interface with hardware, but my programming knowledge is lacking.
Out of curiosity, I'd just like to know:
How does a device driver work, exactly?
When designing a driver for a device, what things do programmers consider?
What languages are drivers written in?
What is the overall process for designing a driver?
I suggest that you read (at lease the first chapter) "Linux Device Drivers". It will answer your basic questions and will allow you to study how to develop device drivers for Linux OS if you want to.
You can find it here: http://lwn.net/Kernel/LDD3/
When designing a device driver, programmers look at the functionalities of the device that are to be implemented and write the driver accordingly
I prefer C / C++ for writing a device driver
but have seen driver in assembly language also
overall process is dependent on device itself

Creating drivers and firmware

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.

Anyone ever tried to develop in C or C++ for Blackberry platforms?

Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.

Resources