Prototyping and simulating embedded software on Windows

g), simulation, and testing of deeply embedded C code on desktop Windows, i= ncluding building realistic embedded front panels consisting of buttons, LE= Ds, and LCD displays (both segmented and graphic).

C code and raw Win32 API rather than MFC,

I don't know why you would want to use Win32 API, rather than MFC. Dealing with plugins are much easier with MFC. For example, you can build an active-x (or whatever they are calling it now) to simulate a segmented LCD, then include it as an MFC class. Unless you want to avoid C++ completely, MFC is much easier than Win32 API.

OK, regardless, do you perhaps know of specific example MFC code for a rendering a graphic LCD with an efficient, pixel-level interface? Or perhaps a class that would render a button with user-defined look for the "depressed" and "released" states?

ndering a graphic LCD with an efficient, pixel-level interface?

I only did segmented LCD active-X. Graphic LCD is more segments (pixels) with different interfaces.

the "depressed" and "released" states?

Can do it with a simple active-x control. MFC will build the class.

Also, I think that MFC is not supported in the free Visual C++ Express edition. But perhaps I'm wrong. Do you happen to know?

ition. But perhaps I'm wrong. Do you happen to know?

That i don't know. I am still using VC 5.0 to compile programs on Window 7. It still works.

Even a very small graphic LCD has thousands of pixels, which is order of ma= gnitude more than most complex segmented LCDs. I simply don't think that th= e segmented-LCD approach (a bitmap for each segment) would scale to graphic= LCDs, especially if you'd like to have grayscale or even very rudimentary = color.

I also look for specific code examples. I already know that "it can be done= ". Internet is full of such claims, but it does not help me.

ition. But perhaps I'm wrong. Do you happen to know?

Actually, my customer compiles my MFC source with VC++ 2008 an d 2010 without problem. So, MFC is supported.

magnitude more than most complex segmented LCDs. I simply don't think that = the segmented-LCD approach (a bitmap for each segment) would scale to graph= ic LCDs, especially if you'd like to have grayscale or even very rudimentar= y color.

So, you need a big buffer in the active-x control and display it in the window. What's the problem?

ne". Internet is full of such claims, but it does not help me.

Yes, but i only work when i get pay, or at least promised to get pay.

I've used wxWidgets to simulate a graphics LCD and UI controls, and added additional windows for debugging assistance (logging, simulation commands to simulate driving UI, command save and replay, regression test and demo support, etc).

wxWidgets works on Windoze and Linux, and builds with free version of VC++. Much easier than messing with MFC or ActiveX (of which I've done too much).

Example:

This code is pretty specific to the device; not at all a generic toolkit....

Hope that helps, Best Regards, Dave

I can understand you want to use low-level tools to get faster code, especially for your simulated LCD displays. But that doesn't mean you have to rule out toolkits of different sorts.

I would recommend you use some sort of gui / widget toolkit to get the basic gui in place. For things like buttons, LEDs and general graphics, you won't be able to make anything better/faster yourself (within a sane level of development effort). For your LCD, you just need some sort of simple widget (an image display widget, for example). Use an off-screen raw bitmap as your "simulation", and regularly copy it onto the widget. It will work more than fast enough, especially if you have the gui running in a different thread from the simulation thread(s).

wxWidgets is a good toolkit, but you need C++ rather than C (or something else entirely - such as using Python to quickly and easily make the gui, while keeping the simulation part in fast C). GTK is probably the most powerful C-based gui/widget toolkit.

Consider also using mingw (gcc for windows) rather than limited free versions of commercial tools. An IDE like Codeblocks will easily let you work with both compilers, so you can see what works best for you.

Thanks a lot for the tips so far. I should probably clarify that my goal is= to create an easy to use toolkit for rapid prototyping of embedded gizmos = on Windows and to release it to the public as *open source*.

Frankly, I'm really surprised that something like this does not seem to exi= st yet. I have quite extensive experience in Qt, for example, but Qt, wxWid= gets, or Microsoft solutions like MFC, ActiveX, or .NET/C# represent quite = a steep learning curve and a big complication for embedded developers. It's= like having to buy a whole pub just to drink a pint of beer.

I mean, all that's really needed for good looking, realistic embedded front= panels is a dialog-box designed with a resource editor (e.g. free ResEdit)= and a couple of custom controls, such as dot-matrix display, segmented dis= play, and owner-drawn button. I also think that embedded folks would apprec= iate direct programming in C, rather than having to jump the hoops of diffe= rent languages (C#, VisualBasic, or even C++).

The use of the plain Win32 API would also drastically simplify the tools. T= he free Visual C++ Express (with Platform SDK) and the free ResEdit should = do it.

I don't mean to start here any religious wars, but, frankly, the GNU-based = tools--and especially the GDB--are horrible for Windows development (this i= ncludes Eclipse with CDT and GDB under the hood). I don't think one can act= ually achieve any true productivity gains with the flaky GDB debugger, whic= h of course defeats the whole purpose of moving the development to the desk= top in the first place. I made this experience with Qt development. I start= ed with the Qt Creator IDE, but quickly got frustrated and disappointed. I = finally switched to Visual Studio and the difference was like night and day= . I was at least an order of magnitude more productive.=20

In the end, the devil is always in the detail. I think that to be really he= lpful, an embedded prototyping toolkit for Windows must include support for= the most productive tools available and *complete* code and examples. I do= n't think that generic statements like "you can draw on an external bitmap"= are helpful.

create an easy to use toolkit for rapid prototyping of embedded gizmos on Windows and to release it to the public as *open source*.

OK, if you go with MFC, i will donate an active X with the following LCD panel. I did a similar simulation before, mostly for demo/presentation. It doesn't matter if MFC is good or bad, most customer asks for it for Window. That's just a fact of life.

Earlier VC++ (5.0, 6.0) can build MFC/ActiveX. VC2008/10 should be able to compile and link them. You might need the paid version to build MFC/ActiveX. Why else do you think MS give free VC downloads?

Sample LCD panel: http://173.224.223.62/meter

compile and link them. You might need the paid version to build MFC/ActiveX. Why else do you think MS give free VC downloads?

In 2004, Microsoft freely released the professional version of VC++

2003 as a command line tool set. There is no IDE, but the compiler, linker, most of the tools and *most* of the libraries are there (see below).

It is no longer available directly from Microsoft's site because they are pushing the "express" versions of newer compilers, but it is floating around on some of the free download sites. The file you want is "VCToolkitSetup.exe" (~31MB).

There are a few gotchas to installation: see

for more information.

If you are interested and have a hard time finding it, I still have a copy somewhere in my archives. George

compile and link them. You might need the paid version to build MFC/ActiveX. Why else do you think MS give free VC downloads?

I would love to get a copy, George, if you are willing to send one. I keep old microsoft tools around. I believe I can accept only

Hi Jon,

That download is good ... it compares identical with the file I have.

I don't have a good way to *send* big files, but I can upload to Google Docs and send you a link to it. Or if you have another drop site where I can upload it, that's fine too.

I grabbed it directly from the MSDN download site when I first heard about it. AFAICT it never was published on any of the MSDN discs.

People who had 2003 professional already have this compiler, the free release was to supplement the 2003 standard edition (what Microsoft now calls "express"). The "tool kit" really wasn't intended for stand alone use, but it can be used with the proper SDKs installed. If your interest is archival, you ought to document the dependencies mentioned on the web page I indicated.

George

Okay. That's great. I've got it now.

No need at this point. Thanks for the confirmation. That's more than I'd hoped to get.

Yeah. I still have my "green" VC++ 1.52C cd-rom from when it was last provided in the MSDN distribution. (They stopped shipping it, but did at one time.) I use it for certain embedded 16-bit x86 applications. One of them I wrote only a few years ago, in fact, with that tool. Another I maintain from many years ago.

Thanks about the reminder on that point. For now, I'm not sure how it may be used. But I'm a pack-rat on old tools. That behavior has been a life-saver for clients in the past.

Jon

simulation, and testing of deeply embedded C code on desktop Windows, including building realistic embedded front panels consisting of buttons, LEDs, and LCD displays (both segmented and graphic).

code and raw Win32 API rather than MFC, .NET/C#, vxWidgets or Qt. I'd also like to use free development tools, such as Visual C++ Express with Platform SDK and ResEdit for editing resources.

24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.

I like BASIC for prototyping because it does most of the complex work for you. VB6 is my favorite because it doesn't need a lot of dotnet stuff.

There's a free compiler similar to visual basic called Xbasic. It's old and no longer supported, but it's free. Source code compatible with linux or windows.

There's a linux program called Gambas3 that looks a lot like visual basic.

PDAs make great graphical interfaces with touch. There's a program called "dialect" that compiles for a PC or a windows PDA.

There's an interpreter called ybasic that runs gui programs for a Palm PDA. Not free, but the demo version has no restrictions.

Both the PDA versions have serial port functionality so you can interface to some real hardware to simulate the low level interaction.

Visual Basic provided the "GUI programming for the masses" and is easy enou= gh, but it does not interface with the C code seamlessly. As I remember, VB= can make calls to DLLs, which might be written in C, but then you need to = jump hoops to debug the separate DLLs. However, maybe my experience is outd= ated. I'd really love to hear if you found a way to easily debug the embedd= ed C code that's the main focus here.

Regarding the free C++ compilers for Windows (such as the compiler from Vis= ual C++ 2003), there is also free Borland 5.5

rticle/20633/). This is also just a command-line toolset.

Miro

On Thursday, August 2, 2012 11:06:41 AM UTC-7, snipped-for-privacy@quantum-leaps.com wrot= e:

ough, but it does not interface with the C code seamlessly. As I remember, = VB can make calls to DLLs, which might be written in C, but then you need t= o jump hoops to debug the separate DLLs. However, maybe my experience is ou= tdated. I'd really love to hear if you found a way to easily debug the embe= dded C code that's the main focus here.

VB can include ActiveX controls written in VC. You can do your main codes = in VB and graphic intensive codes in VC/X/controls. The point is to debug = VC/ActiveX separately. A well written VC/X should not require additional d= ebugging by VB programmers.

VB can't integrate with C code, and certainly can't help with debugging them. It can communicate with DLL's, ActiveX, or external programs (via DDE, OLE, pipes, or network sockets) - but that's far from "seamless". It's a complete mess for non-experts - you would be trying to debug your C code using one tool, and the VB code with a different tool, and trying to figure out what is going wrong during execution (when both parts are active).

VB was a great product up to and including version 3.0 (for Win 3.0). Then Borland Delphi 1.0 came out - for any usage where VB might have been a good idea, Delphi would have been a better idea.

If you want a free command line compiler for Windows, use mingw (gcc for Windows). Borland make good tools - but it's their RAD IDE that makes them good. Their C/C++ compiler is okay, but nothing outstanding - so if you want command line tools, use the best one.

(Intel also makes good compilers, which can be a bit faster for some code. They are certainly free for non-commercial use on Linux - I don't know if there are free Windows versions.)