New project - MSFS C++ USB interface

[Demon]

My new project is slowly taking shape; all the buttons, knobs and switches for a Cessna 152 in MicroSoft Flight Sim 2020.



That was using a utility to get to Lvars, but I can't use it for all my objectives. It doesn't look like much, but I had to get familiar with Visual Studio 2022, learn C++ and get familiar with SimConnect.

I've since moved on to my own standalone Windows GUI in C++. I can finally get to the SimConnect Events, SimVars as well as those dreaded Lvars.



I can get to all the FlightSim controls via my program. Now I have to get the USB communication going between a 18F4550 and my program.

Robert

[Ioannis]

I can only say WOW! In a sort time you did miracles Robert!

Ioannis

[Demon]

I can only say WOW! In a sort time you did miracles Robert!

Ioannis

On the down side, I have to buy a new motorcycle helmet...

[Ioannis]

I feel you!

Ioannis

[Demon]

Looking forward to your progressing on this.

Ioannis

Ok, well here's an update for you.


First I've learned that MS FS buttons and switches are spread over 3 types of data: events, variables and Lvars. I got to get familiar with C++, I can get to events and variables using one "technology", or I can get to Lvars using another, but I can't mix both. I kept reading comments on forums about "just use the SDK also for the Lvars", except I never saw examples.

So after a gazillion attempts at using the SDK to get to the Lvars (I can get to the events and variables just fine), I finally find the SDK support forum and post there. DING! I get a really quick reply to "just do this, it'S in the docs". Yeah, sure, the instructions were crystal clear, but there was a bug in the sample code, and that's exactly what I had been using blindly.

I eventualy gave up, read the instructions word by word, cross-checking against the sample code word-by-word, and it struck me, a variable was missing. Damn! I don't wanna say how long it took me to find that, it's embarassing. But hey, at least the Dev didn't know there was a bug in the sample either.


Then, got the PICkit 4, spent a ridiculous amount of time to get it working, but it's still not quite right. Turns out I found my U2 USB programmer and it works just fine, in fact, it's faster than the PK4. So the PK4 is going into a TO-DO-ONE-DAY drawer...

Been setting up a room into a small shop, putting up all my cabinets and stuff. Turns out I really need to make an inventory system caause now I'm ordering parts I already have, somewhere, that I find the very next day a shipment comes in from DigiKey.

My Aoyue 738 soldering station crapped out; the bits weren't heating at the very tip, even brand new ones. Wasted too much time on that too, gave up and got a Weller WE1010NA from Amazon. Looks decent, haven't tried it much yet except turning on and seeing how fast it heats; real heavy transformer, digital display, comfy non-slip tool that can't fall out the holder (like my antique Weller), and heats super fast.


EasyHID generated obsolete VB6 code, and of course I can't find my VB6 Development CDs. You can't just slap VB6 code into VS2022, so I paid the money and got an upgrade to HIDmaker FS2 cause it seemed to be the answer to my prayers; it can generate PBP3, and .Net C++ WinForm code. Turns out WinForms isn't what I wanted, I just ran off in the wrong direction with that.

Buried in the documentation for the MS FS SDK, there's this requirement:

"To build SimConnect add-ons, the recommended Visual Studio version is Visual Studio 2019, with a minimum version of 2005. To build the project, make sure you have completed the following steps.

For out-of-process applications, start a new Console Application project if the add-on will have no user interface. Start a new MFC Application if the add-on will have a user interface. In either case, set the platform as x64. In order to use the SimConnect functionality, it is required to include the SimConnect.h header file."

Now to me, I saw Visual Studio, and figured VS2022 would work just fine. Turns out, there's more to those requirements than just a need for 64-bit compiling. I had totally forgotten about that MFC part, mainly cause it meant absolutely nothing to me when I read it earlier this year, and started generating C++ WinForms code. Turns out, that was wrong.


So now I'm generating C++ MFC code, but there's a problem, I only notice now that it's generating in Win32 code (x86), and I need Win64 (x64). So I google, and learn to convert from Win32 to x64 straight from inside VS2022, except it ain't that simple, there's an error generated....

And that's where I am today; overcame a truckload of hurdles, learned a bunch of new stuff, got a better idea of what I need and where I'm going. But I don't know enough about Windows to convert, so I'm waiting for support from HIDmaker to guide me along (no complaints about support, he's a one-man show as far as I know, and I have ZERO complaint).

But I will say this, when I compile the PIC code in the 18F4550 on my Lab X1 while the PIC is connected to my PC, DING! The new device is detected instantly; that is such a reassuring sound that I hadn't heard in a long time. Switch over to VS2022, compile the C++ code and Tadaa! The darn thing works, except it's in Win32.

I just have to figure that part out, and then I can start testing against MS FS.

Robert
"Yes, I'm bored cause I'm sitting on my thumbs, instead of going outside to mow the lawn like I'm supposed to before I lose a dog in there"

[Demon]

How to tailor that Windows form to my needs is another problem. It's not the standard super-simple GUI with text boxes and buttons. It uses a formatted Windows system that I'm not familiar with. That's another thing I have to muddle through.

Like this:

[mpgmike]

I have Visual Studio Pro 2015 (paid), VS 2017 Community (free), and VS 2022 Community on my computer. I've noticed many of the YouTube tutorials are using 2017, even though it is 2 versions old. Even though I loaded VS 2022, I have yet to play with it. I have, however, started using the free VS 2017 which does things my Pro VS 2015 cannot.

[Demon]

Actually, it creates the main window, and splashes a familiar sub-window if I'm not connected. As soon as I'm recognized, that pop-up disappears, looked through the code and haven't found it yet.



I have figured out that the "main window" is controlled by Manifest in the project Configuration properties and the Resource file. Gotta google to learn more, never touched that stuff before.

Robert

[mpgmike]

I'm still in limbo without access to my other laptop, but I modified the code so that if I wanted to debug the VB side without actually connecting, I would click "Cancel" and a new pop-up (which I created) would ask if I wanted to work off-line. I remember what I modified was one of the HIDmaker main page routines near the top having to do with On Opening or On Connect or something like that. Look for the code that includes the pop-up and start there.

[Demon]

...
So now I'm generating C++ MFC code, but there's a problem, I only notice now that it's generating in Win32 code (x86), and I need Win64 (x64). So I google, and learn to convert from Win32 to x64 straight from inside VS2022, except it ain't that simple, there's an error generated....

And that's where I am today; overcame a truckload of hurdles, learned a bunch of new stuff, got a better idea of what I need and where I'm going. But I don't know enough about Windows to convert, so I'm waiting for support from HIDmaker to guide me along (no complaints about support, he's a one-man show as far as I know, and I have ZERO complaint).
...

Holy moly, talk about a rabbit hole, searching for "communicating between x86 and x64 C++ programs".

I've narrowed it down to IPC Shared Memory using Boost (staying away from pipes, sockets, RPCs and what-nots). It's been used successfully by a lot of programmers.
https://www.boost.org/doc/libs/1_82_...processes.html

This guy got it working:
https://stackoverflow.com/questions/...24381#63224381

So far, BOOST has come up the most in the threads I've gone through. Now I just have to find a really basic working code. Usually it's just bits and pieces here and there, just enough to get me all excited, but not enough to compile without knowing things like "how to adapt code to your needs without having had a C++ course in your life".

But at least I have an option if HIDmaker can't be adpated to x64 in the near future. It just adds a layer of complexity I could do without.

Robert


EDIT: So how fast can data be transferred using IPC shared memory?



And this is on a Pentium 4, I'm running something slightly faster with a bit more RAM.

I was planning on sharing about that volume of bytes too, 1 or 2 K.

[Demon]

Step 1, made 2 identical programs in 32 and 64 bits, that turn the light ON/OFF only on their side.




Step 2, get them to turn ON/OFF both sides.

... insert cool pic here on soonday ...

Robert

[Demon]

Wow, talk about a roller-coaster (memory getting fuzzy now about exact sequence):

- back in early 2023, I get a basic C++ WinForm GUI running with MSFS SDK, not even knowing what type of program I create (from youtube video).

- decide on upgrading to HIDmaker FS2 to generate PIC and C++ USB code.

- generate USB C++ code, I chose C++ MFC cause I recently saw that in the MSFS SDK docs, compile in x86 ok.

- compile in x64, cause I just saw that again in the MSFS SDK docs, compile failed!

- google migrating C++ x86 to x64, looks like the apocalypse to me.

- figure I'll make a x64 program between the x86 C++ code and the MSFS SDK code.

- start googling, quickly narrow in on Inter Process Communication.- eventually IPC Shared Memory between x86 and x64 stands above the crowd.

- turns out the BOOST group have been working on that, some programmers report success, but never sharing a complete sample.

- I try it using the sample from Boost.org, fail miserably, so I made a rather lengthy post on Stack Overflow asking for help.

- as backup, I find out Adontec produces exactly what I need, just for $400USD, sent then a message to confirm it'll work under my criteria.

- as I'm reviewing the MSFS SDK docs, I notice they say x64 MFC app if you're interfacing "directly" with MSFS, but you can use an ordinary console app if you don't.

- Nothing to lose, so I switch back to C++ Winform, turns out I'm not, I'm just playing with a DLL.

- generate the C++ x86, then compile using x64, and BOOM! The darn thing compiled.


So yeah, been an up-and-down last few days. Hopefully things keep going my way.

Robert


"just a blind man running with a huge smile on his face!"

[Ioannis]

Seems you are very persistent person! And wow, you did an amazing trip through all these environments...!

Respect from me.

Ioannis