1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Prototyping and simulating embedded software on Windows

Discussion in 'Embedded' started by sales@quantum-leaps.com, Jul 28, 2012.

  1. Guest

    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.
    , Jul 28, 2012
    #1
    1. Advertising

  2. linnix Guest

    On Jul 28, 7:54 am, 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.
    linnix, Jul 28, 2012
    #2
    1. Advertising

  3. Guest

    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?
    , Jul 28, 2012
    #3
  4. linnix Guest

    On Jul 28, 11:11 am, 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.
    linnix, Jul 28, 2012
    #4
  5. Guest

    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?
    , Jul 28, 2012
    #5
  6. linnix Guest

    On Jul 28, 11:17 am, 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.
    linnix, Jul 28, 2012
    #6
  7. Guest

    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 graphicLCDs, 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.
    , Jul 28, 2012
    #7
  8. linnix Guest

    On Jul 28, 11:31 am, 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.
    linnix, Jul 28, 2012
    #8
  9. Dave Nadler Guest

    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
    Dave Nadler, Jul 28, 2012
    #9
  10. David Brown Guest

    On 28/07/12 16:54, 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, .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.


    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.
    David Brown, Jul 29, 2012
    #10
  11. Guest

    Thanks a lot for the tips so far. I should probably clarify that my goal isto 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'slike 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 frontpanels 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 forthe 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.
    , Jul 31, 2012
    #11
  12. -for.us Guest

    On Tuesday, July 31, 2012 9:42:35 AM UTC-7, 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
    -for.us, Jul 31, 2012
    #12
  13. On Tue, 31 Jul 2012 10:52:45 -0700 (PDT), -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
    George Neuner, Aug 1, 2012
    #13
  14. Jon Kirwan Guest

    On Tue, 31 Jul 2012 22:18:54 -0400, George Neuner
    <> wrote:

    >On Tue, 31 Jul 2012 10:52:45 -0700 (PDT), -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


    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
    Jon Kirwan, Aug 1, 2012
    #14
  15. David Brown Guest

    On 31/07/2012 18:42, 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.
    David Brown, Aug 1, 2012
    #15
  16. Guest

    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, weare 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 anythingto 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 Iwant 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 postingthe 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/).
    , Aug 1, 2012
    #16
  17. David Brown Guest

    On 01/08/12 18:29, 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
    David Brown, Aug 1, 2012
    #17
  18. On Tue, 31 Jul 2012 20:04:34 -0700, Jon Kirwan
    <> 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
    George Neuner, Aug 1, 2012
    #18
  19. Jon Kirwan Guest

    On Wed, 01 Aug 2012 17:29:22 -0400, George Neuner
    <> wrote:

    >On Tue, 31 Jul 2012 20:04:34 -0700, Jon Kirwan
    ><> 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
    Jon Kirwan, Aug 2, 2012
    #19
  20. mike Guest

    On 7/28/2012 7:54 AM, 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, .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.



    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.
    mike, Aug 2, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mastupristi

    simulating a cooperative scheduler

    Mastupristi, Jan 19, 2004, in forum: Embedded
    Replies:
    3
    Views:
    299
    Ken Lee
    Feb 4, 2004
  2. Bugmaster

    Simulating SPI with AVR Studio

    Bugmaster, Mar 12, 2005, in forum: Embedded
    Replies:
    5
    Views:
    436
    Jeroen
    Mar 14, 2005
  3. Replies:
    3
    Views:
    357
    Jim Granville
    May 25, 2005
  4. Gaines
    Replies:
    0
    Views:
    321
    Gaines
    Jul 15, 2003
  5. Xabier Iturbe
    Replies:
    0
    Views:
    494
    Xabier Iturbe
    Nov 23, 2006
Loading...

Share This Page