Prototyping and simulating embedded software on Windows

[sa...@quantum-leaps.com]

I am looking for tools and techniques for prototyping (virtual prototyping), 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).

I'm specifically interested in a possibly low-level approach, using pure C 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.

I'm looking for code examples to render graphic LCDs (from monochrome to 24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.

[linnix]

On Jul 28, 7:54 am, sa...@quantum-leaps.com wrote:
> I am looking for tools and techniques for prototyping (virtual prototyping), 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).
>
> I'm specifically interested in a possibly low-level approach, using pure 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.

[sa...@quantum-leaps.com]

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?

[linnix]

On Jul 28, 11:11 am, sa...@quantum-leaps.com wrote:
> OK, regardless, do you perhaps know of specific example MFC code for a rendering 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.

> Or perhaps a class that would render a button with user-defined look for the "depressed" and "released" states?

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

[sa...@quantum-leaps.com]

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?

[linnix]

On Jul 28, 11:17 am, sa...@quantum-leaps.com wrote:
> 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?

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

[sa...@quantum-leaps.com]

On Saturday, July 28, 2012 2:17:42 PM UTC-4, linnix wrote:
> I only did segmented LCD active-X. Graphic LCD is more segments
> (pixels) with different interfaces.

Even a very small graphic LCD has thousands of pixels, which is order of 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 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.

[linnix]

On Jul 28, 11:31 am, sa...@quantum-leaps.com wrote:
> On Saturday, July 28, 2012 2:17:42 PM UTC-4, linnix wrote:

> 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?

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

> > I only did segmented LCD active-X.  Graphic LCD is more segments
> > (pixels) with different interfaces.
>
> Even a very small graphic LCD has thousands of pixels, which is order of 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 graphic LCDs, especially if you'd like to have grayscale or even very rudimentary color.

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

>
> 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.

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

[Dave Nadler]

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:
http://www.nadler.com/sn10/ILEC_SN10B_Demo32_237x4.exe

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

Hope that helps,
Best Regards, Dave

[David Brown]

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.

[sa...@quantum-leaps.com]

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 exist yet. I have quite extensive experience in Qt, for example, but Qt, wxWidgets, 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 display, and owner-drawn button. I also think that embedded folks would appreciate direct programming in C, rather than having to jump the hoops of different languages (C#, VisualBasic, or even C++).

The use of the plain Win32 API would also drastically simplify the tools. The 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 includes Eclipse with CDT and GDB under the hood). I don't think one can actually achieve any true productivity gains with the flaky GDB debugger, which of course defeats the whole purpose of moving the development to the desktop in the first place. I made this experience with Qt development. I started 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.

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

[m...@linnix.info-for.us]

On Tuesday, July 31, 2012 9:42:35 AM UTC-7, sa...@quantum-leaps.com wrote:
> 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*.

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

[George Neuner]

On Tue, 31 Jul 2012 10:52:45 -0700 (PDT), m...@linnix.info-for.us wrote:

>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?

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

http://mateusz.loskot.net/2008/09/22/visual-c-toolkit-2003-still-in-use/
for more information.

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

[Jon Kirwan]

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 <10MB per email, though (no limit on the total so
far as I'm aware.) I also did find something that is
supposedly the same thing here:

http://uploading.com/files/HNH73WB3/VCToolkitSetup(v1.01)(2004.07.06).zip.html

I'd like to compare them if you are up to the idea. But if it
is too much trouble to try and send it, I'd understand.
Perhaps you would prefer to just validate that link's
version?

Thanks in advance, regardless.

(I may also check with my MSDN subscription to see if they
keep it up there, too. Would be interesting. They DO keep the
last version of their 16-bit VC++ 1.52C compiler there. Which
is nice.)

Jon

[David Brown]

On 31/07/2012 18:42, sa...@quantum-leaps.com wrote:
> 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*.
>

I like your aim here, but I disagree a bit with your details. Of
course, it's a matter of opinion, taste, and experience - there is no
"right" way to do things. I'm just thinking about what I would do if I
were making such a tool (would that I had time!), or what features I
would like in using such a tool. So read my comments with an implied
"IMHO" at the end of each sentence :-)

> Frankly, I'm really surprised that something like this does not seem
> to exist yet. I have quite extensive experience in Qt, for example,
> but Qt, wxWidgets, 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.
>

If you want to make new development software, don't make it
windows-only. The percentage of non-windows developers is increasing,
and every new version of desktop windows is pushing it further in that
direction, as every new version of windows makes it harder for us
"non-standard" users who dare to use a computer for more than MS Office
and IE. Steadily more tool vendors are moving to cross-platform systems.

This is particularly true when you want to make your tool open source.
The huge potential benefit (to you) of making it open source is that
other people can contribute to it - "open source" is a development
model, as distinct from "free software" (where the "free as in speech"
licensing is the prime motivation) or "freeware" (where zero price is
the motivation). You want to get a community around your tool, so that
you don't have to do all the work - you build the basic frame and a
couple of widgets/components, and hopefully others can contribute new parts.

To encourage such a community, you need to reach as wide a user base as
you can, and you need to make it as easy as possible for people to
participate. You don't do that by arbitrarily cutting out Linux or Mac
users (there are surprisingly many people who do embedded development
work on Macs - at least, /I/ am surprised), especially as your average
Linux developer is much more likely to contribute than your average
windows user.

So don't make it windows-specific - aim cross-platform.

And even for the windows version, don't insist on MS tools (support them
if you want, of course). There are many reasons why people might not
want to have them, even the zero-cost versions - they are big and bulky,
intrusive on the system, won't work on old versions of windows (and
embedded developers are not renowned for updating their systems - XP is
far and away the most common platform), and keep changing. You ruled
out .NET for other reasons, but up until about a year ago MS encouraged
developers that C# and .NET was the language of the future - now with
Win8 .NET is a dead-end.

(For C tools, you might be better off actually making gcc a requirement.
Then you have a known standard platform and your toolkit can
automatically compile the user's code using it.)

> 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 display, and owner-drawn button. I also think that
> embedded folks would appreciate direct programming in C, rather than
> having to jump the hoops of different languages (C#, VisualBasic, or
> even C++).
>
> The use of the plain Win32 API would also drastically simplify the
> tools. The free Visual C++ Express (with Platform SDK) and the free
> ResEdit should do it.
>

I fully agree with your aim - and fully disagree with how you want to
get there.

Of all the possible APIs to use, plain Win32 is the second most
masochistic (pipped at the post by plain Xlib). There are good reasons
why virtually nobody ever uses it for gui work, except at the library
implementation level. If your tool requires users to code to Win32 API,
you will not have many users.


First off, your tool should insulate users from the gui as much as
humanly possible. If they are coding in C, then need to be able to
access the simulator and gui in a way that is as close as possible to
the real hardware.

Secondly, when writing simulation-only code, or support code (such as
for a new gui widget), there is /no/ requirement that it is in C. It
might be convenient that it is /possible/ to code it in C. But users
should be able to use something a lot more powerful and flexible here.
They should be able to write code that uses maths, strings, complex data
structures, etc., without doing the error-prone detail work in C. This
tool is for prototyping and simulation - such work is best done in a
higher level language. The C coding is for the real hardware
implementation later. A good choice of language here would be Python -
it is very high level, and fairly easy to learn. An alternative would
be Lua, which is also quite high level, and has the advantage of being
easy to integrate with C systems. Use the right tool for the job -
don't treat everything as a nail just because you (and your users) have
a hammer.

Rather than making people use "resedit" or other such tools, consider
making your own screen / panel designer specifically targeted for the
job. It would not be /that/ hard - after all, you are not trying to
make a general-purpose form designer.

> 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 includes Eclipse with CDT and GDB under the hood).

No religion here, but plenty of opinions!

The biggest growing IDE for embedded systems is Eclipse. Many, if not
most, major embedded development toolchain vendors either use Eclipse as
their IDE, or are moving towards it. For many processors, gcc is either
the only compiler, or it is at least one of the major compilers. Some
people like these tools, others do not - but those are the facts.

One option that might be worth considering is to base the whole thing on
Eclipse's GEF (Graphical Editing Framework), and make it as an Eclipse
plugin. I don't know how successful that would be, but as it would
integrate with Eclipse you might be able to persuade Freescale, TI,
etc., to sponsor your work to integrate it with their tools.

> I don't think one can actually achieve any true productivity gains
> with the flaky GDB debugger, which of course defeats the whole
> purpose of moving the development to the desktop in the first place.

And you said no religion :-)

No debugger is perfect. I haven't seen any reason to judge gdb as
flakier than other debuggers (and I've used quite a few). A great many
other people seem to manage to use it productively.

> I made this experience with Qt development. I started 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.

So you don't like Qt (again, it's a tool that a great many people /do/
use and like - and again, it's a matter of taste, experience and
opinion). But it seems like a large step to right off all use of gnu
tools because of one bad experience.

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

Well, I hope I've given a few more helpful statements here - even if
they are recommending a different direction for you.

[in...@quantum-leaps.com]

Thank you for all the comments and tips so far. The whole issue of dual targeting embedded software development is very under-appreciated. And yet, we are talking of potential ten-fold productivity gains. This is huge!

@David Brown: Thanks a lot for the thoughtful comments. Well, I think that we need *both* approaches, that is, a simple old-fashioned, Win32 toolkit for pure C programming on Windows only AND a more ambitious cross-platform solution as well. To this end, I fully agree that there is no one "right way" of doing things, and there will be always people who would not touch "Windooze" even with a pitchfork. So, we need both approaches. I'll do anything to get the 10-fold productivity gain. Wouldn't you?

But to get there we need to move from just talking to doing. In this discussion thread, I'm trying to get the ball rolling for the simple Win32 toolkit. I absolutely agree that the Win32 API, invented in the 1980's, is a "masochistic" experience. And that's my whole point. I don't want to deal with BitBlts, Device Contexts, and GDI. Instead I want a couple of simple functions to let me render dot-matrix displays and owner-drawn buttons. For example, I want a function DotMatrix_setPixel(&myLCD, x, y, dark_grey) to very efficiently set a pixel in a display. After many such in-memory operations I want to redraw the display on the screen by calling DotMatrix_redraw(&myLCD).

In fact, after poking around and re-reading some Petzold again, I've already come up with the facilities for: dot-matrix displays, segment displays, LEDs, and owner-drawn buttons. The actual implementation is only about 300 lines of C, but I think it is a good start. I've posted a small demo online at http://www.state-machine.com/win32/front_panel.html. Please note that the real application runs much more smoothly at 30 frames per second than this Flash-demo, which is 15fps at best. Please give me a few days for posting the actual code and an Application Note.

Regarding the more ambitious cross-platform solution, my company has released recently a Qt-based toolkit. An App Note describing it is available at: http://www.state-machine.com/qt/AN_QP_and_Qt.pdf. A screen shot is here: http://www.state-machine.com/attachments/QP-Qt_game.png.

Finally, as a clarification to @David Brown's post, I like Qt a lot, but I moved the Qt development to Visual C++ Pro instead of the free Qt Creator based on GDB. In fact, my company offers a *free* cross-platform modeling tool called QM, which runs on Windows, Linux, and Mac (see http://www.state-machine.com/qm/).

[David Brown]

On 01/08/12 18:29, in...@quantum-leaps.com wrote:
> Thank you for all the comments and tips so far. The whole issue of
> dual targeting embedded software development is very
> under-appreciated. And yet, we are talking of potential ten-fold
> productivity gains. This is huge!
>
> @David Brown: Thanks a lot for the thoughtful comments. Well, I think
> that we need *both* approaches, that is, a simple old-fashioned,
> Win32 toolkit for pure C programming on Windows only AND a more
> ambitious cross-platform solution as well. To this end, I fully agree
> that there is no one "right way" of doing things, and there will be
> always people who would not touch "Windooze" even with a pitchfork.
> So, we need both approaches. I'll do anything to get the 10-fold
> productivity gain. Wouldn't you?
>
> But to get there we need to move from just talking to doing. In this
> discussion thread, I'm trying to get the ball rolling for the simple
> Win32 toolkit. I absolutely agree that the Win32 API, invented in the
> 1980's, is a "masochistic" experience. And that's my whole point. I
> don't want to deal with BitBlts, Device Contexts, and GDI. Instead I

Have you ever /looked/ at the Win32 API? It is /exactly/ BitBlts,
Device Contexts and GDI that you need to deal with - and you need to
track all memory and resources. To add to the joys, it is not even
consistent between different versions of Windows. It is roughly the
same (at least now the Win9x DOS+Windows versions are gone), but there
are lots of corner cases that differ.

The whole point of gui toolkits is to get away from that nonsense.

About the simplest toolkit I have seen is this one:

<http://www.tecgraf.puc-rio.br/iup/>

It has a small pure C API (of around 100 functions, IIRC, while the
Win32 API has hundreds of times as many).


And you'll accidentally get a cross-platform solution (IUP works on
Linux, Windows and Macs), as well as having full support for Lua (which
I mentioned as a good choice for an alternative/additional language).

> want a couple of simple functions to let me render dot-matrix
> displays and owner-drawn buttons. For example, I want a function
> DotMatrix_setPixel(&myLCD, x, y, dark_grey) to very efficiently set a
> pixel in a display. After many such in-memory operations I want to
> redraw the display on the screen by calling
> DotMatrix_redraw(&myLCD).

However you make this thing, you will probably be best doing that by
drawing to an off-screen bitmap (using "setPixel" functions) then
copying it onto an image or canvas widget (your "redraw" function).

>
> In fact, after poking around and re-reading some Petzold again, I've
> already come up with the facilities for: dot-matrix displays, segment
> displays, LEDs, and owner-drawn buttons. The actual implementation is
> only about 300 lines of C, but I think it is a good start. I've
> posted a small demo online at
> http://www.state-machine.com/win32/front_panel.html. Please note that
> the real application runs much more smoothly at 30 frames per second
> than this Flash-demo, which is 15fps at best. Please give me a few
> days for posting the actual code and an Application Note.
>
> Regarding the more ambitious cross-platform solution, my company has
> released recently a Qt-based toolkit. An App Note describing it is
> available at: http://www.state-machine.com/qt/AN_QP_and_Qt.pdf. A
> screen shot is here:
> http://www.state-machine.com/attachments/QP-Qt_game.png.
>
> Finally, as a clarification to @David Brown's post, I like Qt a lot,
> but I moved the Qt development to Visual C++ Pro instead of the free
> Qt Creator based on GDB. In fact, my company offers a *free*
> cross-platform modeling tool called QM, which runs on Windows, Linux,
> and Mac (see http://www.state-machine.com/qm/).

I've added that link to my "things to look at" bookmarks list.

mvh.,

David

[George Neuner]

On Tue, 31 Jul 2012 20:04:34 -0700, Jon Kirwan
<jo...@infinitefactors.org> wrote:

>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 <10MB per email, though (no limit on the total so
>far as I'm aware.) I also did find something that is
>supposedly the same thing here:
>
>http://uploading.com/files/HNH73WB3/VCToolkitSetup(v1.01)(2004.07.06).zip.html
>
>I'd like to compare them if you are up to the idea. But if it
>is too much trouble to try and send it, I'd understand.
>Perhaps you would prefer to just validate that link's
>version?

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.

>Thanks in advance, regardless.
>
>(I may also check with my MSDN subscription to see if they
>keep it up there, too. Would be interesting. They DO keep the
>last version of their 16-bit VC++ 1.52C compiler there. Which
>is nice.)
>
>Jon

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

[Jon Kirwan]

On Wed, 01 Aug 2012 17:29:22 -0400, George Neuner
<gneu...@comcast.net> wrote:

>On Tue, 31 Jul 2012 20:04:34 -0700, Jon Kirwan
><jo...@infinitefactors.org> wrote:
>
>>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 <10MB per email, though (no limit on the total so
>>far as I'm aware.) I also did find something that is
>>supposedly the same thing here:
>>
>>http://uploading.com/files/HNH73WB3/VCToolkitSetup(v1.01)(2004.07.06).zip.html
>>
>>I'd like to compare them if you are up to the idea. But if it
>>is too much trouble to try and send it, I'd understand.
>>Perhaps you would prefer to just validate that link's
>>version?
>
>Hi Jon,
>
>That download is good ... it compares identical with the file I have.

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

>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.

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

>>Thanks in advance, regardless.
>>
>>(I may also check with my MSDN subscription to see if they
>>keep it up there, too. Would be interesting. They DO keep the
>>last version of their 16-bit VC++ 1.52C compiler there. Which
>>is nice.)
>>
>>Jon
>
>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.

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.

>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.

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

[mike]

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.

[sa...@quantum-leaps.com]

Visual Basic provided the "GUI programming for the masses" and is easy enough, 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 outdated. I'd really love to hear if you found a way to easily debug the embedded C code that's the main focus here.

Regarding the free C++ compilers for Windows (such as the compiler from Visual C++ 2003), there is also free Borland 5.5 (http://edn.embarcadero.com/article/20633/). This is also just a command-line toolset.

Miro

[m...@linnix.info-for.us]

On Thursday, August 2, 2012 11:06:41 AM UTC-7, sa...@quantum-leaps.com wrote:
> Visual Basic provided the "GUI programming for the masses" and is easy enough, 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 outdated. I'd really love to hear if you found a way to easily debug the embedded 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 debugging by VB programmers.

[David Brown]

On 02/08/12 20:06, sa...@quantum-leaps.com wrote:
> Visual Basic provided the "GUI programming for the masses" and is
> easy enough, 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 outdated. I'd really love to hear if you found
> a way to easily debug the embedded C code that's the main focus
> here.

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.

>
> Regarding the free C++ compilers for Windows (such as the compiler
> from Visual C++ 2003), there is also free Borland 5.5
> (http://edn.embarcadero.com/article/20633/). This is also just a
> command-line toolset.
>

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.)

[mike]

replied in an attempt to get off the reply list so I stop getting emails.

[Miro Samek]

Mike,

If you receive too much email from a Google group, like comp.arch.embedded, you need to change your membership settings.

To do so, you click on "My membership" button at the top of your browser window. This opens a dialog box, in which you can select the "No Email" radio button.

Miro

[celep...@gmail.com]

I'll second this, you can pick up how to use WxWidgets in a few hours, either in C++ or Python (my choice), and your application can just be done by writing to a bitmap of the same dimensions as the LCD and then copying it to a window. Buttons and all the other controls are easy to implement.
If you use Python there is a wonderful collection of demos that will get you half-way there, and there is an excellent book available on WxPython, I know it's good, I lent out my first copy and I never got it back!

[j.m.gr...@gmail.com]

On Wednesday, August 1, 2012 4:42:35 AM UTC+12, Miro Samek wrote:
> 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 includes Eclipse with CDT and GDB under the hood). I don't think one can actually achieve any true productivity gains with the flaky GDB debugger, which of course defeats the whole purpose of moving the development to the desktop in the first place. I made this experience with Qt development. I started 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.
>

I believe Atmel changed to Visual Studio with their latest Studio 6.
We can be sure they looked at other options.

Did you see this announcement ?
https://emeapressoffice.oracle.com/Press-Releases/Oracle-Releases-New-Java-Updates-Java-SE-7-Update-6-JavaFX-2-2-and-JavaFX-Scene-Builder-1-0-3064.aspx

Claims to support Windows, and "Full Mac OS X Release, Expanded Linux on ARM Support in Java SE and New Linux Version of JavaFX", and also claims

"The new JavaFX Scene Builder is a visual layout tool for the JavaFX platform that enables users to design user interface (UI) screens by simply dragging and positioning components from a palette onto a scene."

If you are trying to emulate Graphics LCD, you need to decide where to 'slice' the emulation.
A final Embedded Microcontroller solution, is likely to have a Pixel Font Rom, and some low level Graphic chip driver code.
Emulating all of that, is highly complex.

You might be able to practically provide desktop emulation with calls to LCD writes, that would support buttons and interaction tests, and with imported fonts could get closer to the final user product, but it is unlikely to be pixel perfect.
Sounds like that newest Java release could work well, and it is OS portable.
I see they even try to appear trendy, buy mentioning the Raspberry Pi.

[j.m.gr...@gmail.com]

On Wednesday, August 1, 2012 4:42:35 AM UTC+12, Miro Samek wrote:

> 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*.

Just to clarify, you are using 'emulate' in the broader sense, and intend to recompile only portions of a users embedded code, to run on windows.
You are not targeting processor emulation, or even ASM emulation, but are working only at 'C' source level and there, above a uC SFR access level.

If your intention is only upper level C 'emulation' by recompile, why not just use Visual Studio, expanded with some libraries ?
Perhaps with a 'double wrapper' on the libraries, as users will have widely varying schemes for their final embedded Button and rendering calls.

Thus a mid-level of 'parameter house keeping' would allow lowest level lib updates to be applied to your emulation, and I guess once working, such a mid-level house keeping system could call a USB link, to access real hardware.

-jg

[Paul]

In article <c4dc29ca-7eb5-4ffa...@googlegroups.com>,
celep...@gmail.com says...
>
......

>
> I'll second this, you can pick up how to use WxWidgets in a few hours,
> either in C++ or Python (my choice), and your application can just be
> done by writing to a bitmap of the same dimensions as the LCD and then
> copying it to a window. Buttons and all the other controls are easy to
> implement.
>
> If you use Python there is a wonderful collection of demos that will
> get you half-way there, and there is an excellent book available on
> WxPython, I know it's good, I lent out my first copy and I never got
> it back!

Well do you have a particular name for that book as I have someone
wanting to try it out.

Title or ISBN would help.

--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[in...@quantum-leaps.com]

I'm really surprised that nobody here could recommend an existing library or an open source project, which would provide a simple C-only interface to the basic GUI elements, such as LCDs, buttons, and LEDs. This is really not that complicated, yet it seems that every embedded developer has to re-invent this wheel over and over again.

So, to help embedded developers interested in prototyping embedded devices on Windows, I have created a "Front Panel Win32 GUI Toolkit" and have posted it online under the GPL open source license (see http://www.state-machine.com/win32). This toolkit relies only on the raw Win32 API in C and currently provides the following elements:

1. Dot-matrix display for an efficient, pixel-addressable displays such as graphical LCDs, OLEDs, etc. with up to 24-bit color

2. Segment display for segmented display such as segment LCDs, and segment LEDs with generic, custom bitmaps for the segments.

3. Owner-drawn buttons with custom “depressed” and “released” bitmaps and capable of generating separate events when depressed and when released.

The toolkit comes with an executable example and an App Note (see http://www.state-machine.com/win32/AN_Win32-GUI.pdf), showing how to handle input from the owner-drawn buttons, regular buttons, keyboard, and the mouse. You can also view an animated demo at http://www.state-machine.com/win32/front_panel.html.

Regarding the size and complexity of the "Front Panel Win32 GUI Toolkit", the implementation of the aforementioned GUI elements takes only about 250 lines of C. The example with all sources of input and a lot of comments amounts to some 300 lines of C. The toolkit has been tested with the free Visual C++ Express 2010 (with the Express Edition Platform SDK) and the free ResEdit resource editor.

Enjoy!

[Dave Nadler]

Very nice Miro !
Will you be at ESC in a few weeks ?
Hope to see you there,
Best Regards, Dave