Stand-alone G5

[grizzled kelp]

I'm about done with a stand-alone G5 instrument using the 4" 480x480 LCD, it's associated ESP-32-S3 LCD Driver module and an RP2040. By "stand-alone" I mean all the display logic is in the device; it's not an HDMI monitor dependent on another G5 add-on.

The basic architecture uses the ESP32 as a custom MobiFlight device which drives the display and handles communication. I wanted the device to have a power button, power LED and a single encoder + button to mimic the real thing. However I couldn't figure out how to free up the five GPIO pins I would need, so I set up an RP2040 as a I2C slave to manage the inputs and send the input signals (rotary inc/dec, button press, etc) back to the ESP32.
After chatting with @elder star I think I should have used the RP2040 as the MobiFlight device and made the ESP32 the slave device to manage all the display calculations and functions. (So I'd be sending the all the MSFS variables over the i2c bus to the display.) This would balance the load across the two devices better and possibly improve frame rates.

Currently I only have the HSI coded. I'll try the different approach to do the PFD mode next.

I've tried to incorporate all the features of the real G5 as best as I could figure them out from the manual, YouTube videos, and comparing it to the G1000 functions. It has GPS and radio nav modes, glideslope and CDI offset display. The heading bug moves with the encoder and the menu function is implemented (adjust heading and course, but no "settings" menu yet.) I've not done bearing pointers yet, still debating if it's worth the work.

The code is up on my github, but I'll say that it needs a significant refactor. I made some bad, early decisions with the menu feature and it's kind of messy. I'm going to see how the PFD code turns out before refactoring. Still, this was a very fun challenge!

[slate apex]

whoa this is super nice!

[elder star]

This looks amazing!!

[slate apex]

I am wondering if this would work with the Guition screens

they are kinda nice form factor and have a nice case, of course no knobs but one could add that in a 3d printed piece

[elder star]

Yes, it will, but it needs some rework. I already discussed the possibility with @grizzled kelp 😃

[grizzled kelp]

Yep! That's what I'm going to try with the PFD edition of this instrument. If that goes successfully, I could see trying to drive two "slave" Guiton screens with one master i2c RP2040 running mobiflight and managing the encoders/buttons. However I think that setup would pull about 450mA so could be nibbling at the limit of a single USB cable power power limit.

[slate apex]

also of course g5 is widescreen and not a square

[grizzled kelp]

Correct. If you compare the screen layout of mine to the real thing you'll see it's a little off.

One kind of hacky thing I had to do (you may have a better suggestion, @slate apex , is I needed to send back encoder up/down messages to the MF PC client. However I could not use the MF interface to add a button/encoder as all the pins are in use on the ESP32. So, I send the encoder up/down and button actions with cmdMessenger and MF client sees them. Cool! But you cannot use the UI to assign them to MSFS functions because there are no encoder devices assigned to the board. So I had to edit the MF .mcc file by hand to add them. That works, but I don't really like it.

Could I add a "pinless" encoder to the custom device definition somehow?

[slate apex]

you can do like Neil does

[grizzled kelp]

Funny enough, you can see the config if the device is disconnected but not if connected.

[slate apex]

void OnGetConfig()
{
Serial.println(F("10,1.0.L1:1.1.L2:1.2.L3:1.3.L4:1.4.L5:1.5.L6:1.6.MSG:1.7.DIR:1.8.IDX:1.9.TUN:1.10.A:1.11.H:1.12.O:1.13.V:1.14.FPLN:1.15.B:1.16.I:1.17.P:1.18.W:1.19.LEGS:1.20.C:1.21.J:1.22.Q:1.23.X:1.24.DEP_ARR:1.25.D:1.26.K:1.27.R:1.28.Y:1.29.PERF:1.30.E:1.31.L:1.32.S:1.33.Z:1.34.DSPL_MENU:1.35.F:1.36.M:1.37.T:1.38.SP:1.39.MFD_ADV:1.40.G:1.41.N:1.42.U:1.43.DIV:1.44.MFD_DATA:1.45.1:1.46.4:1.47.7:1.48.DOT:1.49.PREV:1.50.2:1.51.5:1.52.8:1.53.0:1.54.3:1.55.6:1.56.9:1.57.PLUSMINUS:1.58.R1:1.59.R2:1.60.R3:1.61.R4:1.62.R5:1.63.R6:1.64.EXEC:1.65.NEXT:1.66.CLR:1.67.BRT:1.68.DIM:1.69.DEL:3.70.Brightness:;"));
}

ie, just send a hardcoded string

make a setup like you would like on a regular firmware

then do 12;

on the serial monitor to get a string

and just send that

https://github.com/neilenns/Collins-FMS-3000-Firmware/blob/main/src/mobiflight.cpp#L190C1-L194C1

you will never change the devices anyway since it is a dedicated custom panel

[grizzled kelp]

I'll look at that...hadn't thought of doing it that way. I was just doing this:
void sendEncoder(String name, int count, bool increase)
{
// cmdMessenger.sendCmdStart(kButtonChange);
for(int i=0; i<count; i++) {
cmdMessenger.sendCmdStart(kEncoderChange);
cmdMessenger.sendCmdArg(name);
cmdMessenger.sendCmdArg(increase?0:2);
cmdMessenger.sendCmdEnd();
}
}

[slate apex]

yeah, that plus the OnGetConfig likely is what is needed so that you can add input configs for those

otherwise you just get events but MF does not know there is an encoder even though it sends events

[grizzled kelp]

Exactly. That's why I hand edited the config. I never thought of overriding the kInfo response. Good idea.

Thank you!

[slate apex]

that's @stone egret idea originally, he had a custom device before custom devices were cool, and his is an input device 🙂 a keyboard matrix chip

[supple coral]

The actual FW source has a compile flag for a config saved in the flash.
Or was it in the community device source? 🤔

Yes, the compile Flag is HAS_CONFIG_IN_FLASH. In the community template repo you can see how to use it.

[grizzled kelp]

I will look at that. I'd seen it, but never understood what it was for or when you'd want to use it. Guess this is it! Thank you

[supple coral]

If you set this flag an array with the config has to be defined. That's it.
An example of the array and the required name is in the template repo.
If you want to use it with the "standard" FW source make sure that the file with the array is in one if the include paths or add the position to the platformio.ini

[grizzled kelp]

And the actual pin numbers used don't matter?

I.e. the pins won't be initialized in the main MF code

(Going to the repo to take a fresh look now)

E.g. I want to create two virtual encoders. Within my code I will send updates for encHeading and encCourse. Can I just use "8.99.99.0.Encoder Heading" and "8.99.99.0.Encoder Course"

const char CustomDeviceConfig[] PROGMEM =
{
"1.2.Button Flash:"
"8.3.4.0.Encoder Flash:"
"11.54.5.Analog Input Flash:"
"12.7.6.5.1.InputShifter Flash:"
"14.12.8.9.10.11.2.Multiplexer Flash:"};

(I know I can just test...but figured if you're here 🙂 )

[stone egret]

They'll show in the UI but it doesn't matter, you'll never use the modules dialog

[supple coral]

Yeah, that should work.

The encoder class tries to initialize the pins, but it wont be done as 99 is not a valid pin.

[grizzled kelp]

I'd tried this before...defining fake pins in the board definition. Doing it with Config In Flash I get the same result:
[ 78959][E][esp32-hal-gpio.c:190] __digitalRead(): IO 99 is not set as GPIO.
[ 78965][E][esp32-hal-periman.c:180] perimanGetPinBus(): Invalid pin: 99
In a tight infinite loop.

(The encoder handler is trying to read invalid pins.)

I think what I really need are additional custom devices in my project: Encoders that don't use pins.

But afaik there's no custom input device, only output.

[grizzled kelp]

Overriding OnGetConfig gives me the results I need. Thank you. I hate modifying the core, but I think I'd rather mod it this way than edit the encoder handling code.