Develop Reference

CANopen windows library, multiple devices

I am going to write Windows application (for commercial use) which will send/receive and trace CANopen messages.
The problem is I don't know what devices will be used by users of this app.
Currently I have one requirement to support only USB-CAN devices.
However there is many vendors of such devices and everyone has other api/library/dll to use theirs devices.
(By the way, the problem is because I have to use Windows.
As I know on Linux is SocketCAN and everything is more standardized :-()
I don't know which library should I use. Could you recomend me something.
Of course this library should support as many vendors (and drivers) as possible.
Second requirement is this library shall compile to IL or somehow I can use this library in my C# application.
I have done small research:
The most popular is CAN Festival but it is abandoned project, however there is a few forks.
There is CANopen for .NET
But support only PEAK devices and state is prealpha
CANopen for Python
Support more devices but state is also alpha and I don't know if I can use this library in my c# application. Maybe when I use IronPython.
I also found this library: http://www.emtas.de/en/allgemein/csharpapi. It is commercial, but If support many devices I can buy It. Anyone has used it before??

We are using and have licensed the Swedish datalink.se CANopen library and it works very well for us. But honestly we are only using the CAN interface driver layer on Windows, for accessing a range of devices like Lawicel, Kvaser, IXXAT a.s.o. I haven't looked at the CANopen parts so much.
I looked at other CANopen SW stacks, too, back then, but like you I wasn't happy about CAN Festival. So what we do in our Kickdrive software is that we implemented just the amount of CANopen that we really need. See my answer in the post How to program a simple CANopen layer.
Depending on what are your actual requirements, this might be good enough already, or even the best approach.

VOIP in C#, asp.net or Java

Could you people please give some good resource / ideas of implementing VOIP in c#.net, Asp.net or Java.
Why I am specifying 2 different language platforms is we are yet to take up a call.
Basically we don't have the idea henceforth the concept is more important to us.
We are going to make a White board application and one of the client requirement is
White board should have VOIP
conferencing, chat image sharing and
ability to upload .pdf files

I reckon your looking into developing software like orange business webex or something similar. The software is not too difficult to develop. First, are you planning to write the entire application yourself or just purchase the components and integrate ? I would recommend you shop around for components and just integrate because VOIP is rather complex.
Here is a link for SIP communicator in java which supports VOIP

Doing simple point-to-point VOIP isn't too difficult. Basically, you need a codec on each end, and then typically use UDP to send encoded packets from one end to the other.
There can also be network connectivity issues, particularly related to NAT.
If you want to interoperate with existing VOIP-based systems, then you will need to support one of the underlying connection protocols, such as H.323, and you may also need monitoring and control over RTP. Those protocols are notoriously complex.
There are a bunch of tricks to play when doing this kind of thing with a managed language like C# or Java, particularly related to avoiding hiccups due to GC.

A link to a few more Java VOIP projects/components:
http://voip.dev.java.net/
One "gotcha" to beware of, in terms of future functionality, is that Java's (as opposed to JavaFX's) video support is something of an open question at the moment.

Is Mono stable and fast enough? [duplicate]

This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).

Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.

ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.

You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.

I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo

as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.

C++ or C# to program mobile barcode device?

I will be developing some applications using mobile barcode scanners and need to choose between C++ and C# for coding on the scanners.
I am considering Intermec's CK31 or similar for the combination of wifi, scanning choices, programmability and user interface options. It runs Windows CE .NET 4.2 according to their spec sheet.
Intermec's Developer Library comes with .Net and C++ SDKs. My previous Win CE 2003 experience is in C++ (MFC GUI, sockets and serial comms). I'm comfortable in C# with WPF and can learn other GUI frameworks if I have to. That gives me freedom to choose a language - any recommendations one way or another?
I am NOT looking for answers advocating C++ over C# as languages in general - my productivity in either is similar and I have enough experience to be able to create complex, robust C++ solutions.
What I would appreciate are war stories or factors to put into our platform evaluation, about programming on these devices. eg: battery life of C# apps vs C++ apps, memory consumption or other environmental impacts of the language choice. If there are specific versions of .Net CE to avoid, that would be a good tip.

I've been designing and developing software for Windows Mobile and Windows CE in C, C++ and C# for quite a few years now. Moreover, I been doing so for Honeywell (formerly Hand Held Products, purchased by Honeywell in 2007) where I've worked on nearly all aspects of the devices, from drivers and services to Line of Business GUIs and utilities.
First of all, I won't tell you one language is better than the other... I probably spend a 50/50 split of my time with each, and each platform definitely has their own place in the mobile development.
I will however, give a suggestion that you likely stay away from any device that runs an OS as old as WinCE 4.2, especially if you are even considering .NET development. The reasoning for this is that 4.2 only has, at most, .NET CF 1.0 embedded in ROM (part of the OS ROM image), meaning that you would require a ~5MB CAB file to install at least .NET CF 2.0 Yes, you could develop with CF 1.0 but, truly, it's not worth the pain of using such an old framework. Most WinCE 5.0 devices these days come with CF (Compact Framework) 2.0 installed in the ROM so I would at least look for that.
On that same vain, you may even want to consider using a device with Windows Mobile 6.0 or 6.1 as they are easy to program with and will always have CF 2.0 pre-installed. In case you're wondering why I have not mentioned CF 3.0 or CF 3.5, it's just because the first Mobile platform to be release with those versions will be Windows Mobile 6.5, which is not out yet. Though you can always install the framework if you want (~8MB CAB).
Granted, WinCE definitely gives you a more "Windows" look and feel to its GUI over its Windows Mobile cousin, so that is all a matter of your programming preference and what your end users want and need.
Regarding kgiannakakis's comments on SDKs being only a thing layer, this is just not true. If you have a proper SDK you should have all of the same access to any devices or drivers that you would in C++ but with the ease of C#. For example, Honeywell provides an extensive SDK for all of our devices in C++, VB and C# and the C# portion of the SDK actually has more functionality than the C++ portion. You will never have to do a P/Invoke with our code from C#.
If you want to take a look at the SDK I'm talking about, it's freely available to download here and has some great examples.
IMHO I would actually consider the provided SDK as more important than the hardware in many cases since, most of the time, the hardware for the devices is pretty much the same. They all have ARM CPUs, WiFi, Bluetooth, Laser or Image based scanners, etc.
Though, I looked at the Intermec link you posted and it doesn't look like that unit actually has a built in scanner...are you using an external scanner hooked to the device?
Take a look at the Honeywell offering if you want here. We've got devices with probably the best imager based bar code scanner in the business, built into all of our units. And we have a rock solid SDK (I should know, I wrote a lot of it). And the SDK provides .NET extremely access to all of the hardware on the device. Ok...I'll stop my sales pitch now.
As for one language over the other...it really all depends on what exactly you want to do.
Drivers and services cannot be written in anything but Native (Win32) C or C++. So .NET is out for anything like that.
C and C++ can absolutely be your friend on mobile devices in terms of keeping things lightweight, since you don't need the whole .NET framework to run the add. Remember, you have a maximum of 32MB of memory for any process (not including DLLs..that's another lecture) so if your application is going to be processing a ton of data, C++ may be the way to go.
One of the major disadvantages I've found to C and C++ on mobile systems, however, is that making a GUI is way harder than it is with .NET Actually, most of the C++ apps I write are completely headless and have no GUI at all... .NET CF does not have WPF (yet), and is stuck with WinForms, but it's really easy to pick up. Pretty much drag and drop in the designer. And also remember, like I mentioned before, that WinCE has a completely different GUI paradigm than Windows Mobile. However, sometimes the Windows Mobile way is kind of nice, since it forces you to keep your GUIs simple and to the point.
Memory consumption can be higher when using .NET, but not always. For one, having a device with the version of the CF you are going to use stored in ROM will mean that you will generally have no more memory used on a .NET application vs the equivalent C++ app. In some cases, .NET will even use less memory. For example, a .NET app vs a C++ app that uses MFC can often use less memory because the C++ app has to load up the MFC framework (since it isn't already loaded by the OS...).
Also, since C# is managed, you will often end up with less memory usage because the garbage collector is freeing up memory that you may have forgotten to do in a C++ app.
Execution speed on more modern devices is generally no different between the two. Granted, you will always have little parts of each language where one will be faster than the other, but .NET is mature enough at this point that the speed is not really a concern. I have programmed extremely fast applications with highly interactive, animated GUIs that ran just fine on a device with 128MB RAM and a 420MHz ARM CPU. I even wrote one app that I had to slow down because it was calling into a native DLL via P/Invoke and the .NET portion was essentially getting "Impatient."
I have never seen any issues with battery life in one language vs the other. But I've never specifically tested for it either.
I really think that, in the end, it still comes down to the SDK that comes with your device of choice. If it has poor .NET support then you will find your self doing a lot of extra work getting everything to work, in which case I would go with C++. But if it has great .NET support (like the one I work on) you will find yourself with a lot less work and probably get the job done significantly faster.
Also, remember that it's not just the SDK of the hardware vendor you have to take into account. While you need that specific SDK as each device is different (i.e. the SDK I linked to earlier will not work on that Intermec device) all of the non-hardware related OS stuff is pretty much standard across the board, which is where the Windows Mobile or Windows CE SDK from Microsoft comes in. Their C++ support is pretty good, but they are really pushing all things .NET these days, so as updates are made to the OS, less updates are made to the C++ SDK and much more functionality now relies on using .NET Not that you couldn't do it in C++, it's just that they haven't done a lot of the work for you that they did do in the .NET SDK.
Ok...that was long, but I was trying to dump the finer parts of my years of experience into one thing. I hope it made sense.

The answer to your question has to do with the type of your application. If your application is mainly around communicating with the hardware and only a thin layer of business logic and User Interface is needed, then C++ would be a better choice. To interact with the scanners you need to talk to a driver. This is better and faster achieved with C++. The .NET SDK will actually be a wrapper of C++ code using a ton of P/Invoke, which makes the code performing less faster.
If on the other side your application requires a significant business layer and/or a User Interface, then .NET (and specifically C#) is a better option. In that case the productivity gains far out weight the performance gains of C++.
Another important factor is the type of the devices the application is going to be deployed to. Are you targeting Windows Mobile devices only? Then .NET is a safe option. For Windows CE devices you need to investigate whether the compact framework is pre-installed or not. Also, some Windows CE devices may not support all .NET namespaces.
Finally, I recommend reading Mobile Architecture Pocket Guide, which is a recent document about architectural decisions for mobile applications.

First I'll strongly echo Adam's recommendation against running anything based on CE .NET 4.2 at this point for essentially the same reason. At this point it's an ancient version of the OS and unless you are getting the terminal for free it's not worth it and if you choose to do C# development the download of the CAB to run .NET 2 is just painful.
We've developed a lot of applications for both Motorola(Symbol) and Intermec devices. The current set of APIs for both of them work reliably so I'd worry more about the suitability of the device than the specific APIs. They also both provide reasonable sample programs that make it easy to cut and paste a solution.
I have noticed one other big difference between Motorola and Intermec. On the Intermec devices I've worked with (in C#), it takes about a second for the decoder for each symbology to be loaded. This typically isn't a big deal if you use a limited number of symbologies and setup the scanner at the start of the application, but can cause significant delays if you change the decoders(symbologies) within the application.

I've been developing for about 15 years. Approx 5 years in C++ and 3 years in C# (which currently is my language of choice). In C++ I always used stdlib, and sometimes boost.
I have cut my development time with a third since I switched from c++ to c#. That was done because of a couple of things (nothing scientific, just my opinons):
.Net is a more complete framework and easier to use than stdlib and boost combined.
C# has a better structure which make easier to read others code and to code.
Unit testing in .Net is light years from unit testing in C++, especially with Resharper and xUnit (xUnit got clean syntax, resharper let's you test specific test methods directly inside dev studio).
I mostly code servers, GUI programming should be even faster.

Real world cost to run WinForm apps on mono?

My company has an existing established WinForm application which in running on WinXP. The application does alot of sound processing using DirectSound.
My company would like to evaluate Mono, as an alternative on a per workstation cost to Vista/Win Server 2008.
I've heard that different estimates, ranging from 'it will work easily on Mono' to 'it could take months of recoding in certain cases to get a WinForm app to run with Mono on Linux'.
Does anyone have a good real world experience with this?
A good link reference?
I would like to get a better idea before I commit to testing.
Thanks!

The WinForms part will be easy, you may have to do very little as Mono now claims to support Winforms 100%, however all the DirectSound calls will have to be rewritten to use an API available on Linux, ALSA being the obvious choice.
I have written small apps in VS 2005 and ported them with ease to Mono. If you do a lot of P/Invokes, then you'll have to take that into account, as those may have to be completely rewritten or rethought.
Also, check out MOMA: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project."

Mono can help you move the managed code, but it will not help you move the audio layer.
Sadly, the .NET framework does not provide a comprehensive API for audio processing. It merely provides a way of playing back a small sound sample, and it is not even very good at this (See Jeroen's post about audio gaps when running the C64 emulator under IKVM).
You will have to research which Linux API maps best to what your audio application is doing.
Lennart Poettering blog entry on audio is an excellent starting point:
http://0pointer.de/blog/projects/guide-to-sound-apis.html
Once you decide on an API, just like in Windows, you will have to P/Invoke the API that is right for you.