Prototyping and simulating embedded software on Windows

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, VBcan 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

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.

On 02/08/12 20:06, 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.)

On 8/2/2012 11:06 AM, 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.
>
> 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

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

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

On Sunday, July 29, 2012 6:07:23 AM UTC+10, Dave Nadler wrote:
> 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

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 toa 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!

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 (thisincludes 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/P...-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 tobe 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.

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

In article <c4dc29ca-7eb5-4ffa-a3c3->,
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 |
<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

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 notthat 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!