Request for some code architecture guidance: sending messages

Hello!
Some background: I have relatively fundamental skills in C++, but I think I can get some things done if I get general code architecture guidance, so I’d like to seek feedback on what I would like to do and whether my understanding of the major components is correct.

I will be working on integrating a Q10 keyboard circuit and most likely a 2 axis nav switch in a new interface, likely a 1.8in TFT. Meaning I am going to work on a fork that will fundamentally no longer work with a bluetooth app but rather in autonomous fashion (I guess they could also work concurrently).

I think the high level of what I have to do in the code feels like the following:

  1. Introduce another loop IFDEF within main.cpp that will check keyboard/inputs.
  2. Introduce a distinct screen class and its set of IFDEFs (sorry, I dont have accurate linguistics for those). That screen class will be based on ILI9341 or ST7735, as opposed to the existing SH1106/SSD1306. Those are SPI devices, probably need to be DEFed in as a ?platform? option
  3. While the screen already receives a copy of the messages, I would also need to support sending messages. Thus I will need to find out how I can call the PhoneAPI::handleToRadio() function to send a string, for instance.

My current challenges are mostly around 3 above, since I dont really see an “easy” way to just send function that accepts a char[], let alone a String.

I have a clear tendency to chew more than I can take - if anyone can give me generic guidance, confirm if my understanding above is good (or perhaps that I am patently insane), I would truly appreciate that…

Mat

2 Likes

That sounds like approximately the right plan. I’ll reply in the next dayish with more detailed comments.

Thanks! I’ll spend more time decoding things and do my homework. This at least seems to confirm I am not nosediving… :smiley:

1 Like

btw: If you want to see examples of how other places in the code are sending messages grep for allocForSending(), the functions that are calling that typically call that, fill in some fields and then call router->send(packet). You could add a “MeshService::sendTextMessage” method and then use that method to do your new hotness.

If you play with the python tool’s command line send text message option, you can watch how it fills in the fields (with --debug) and sends messages for the texts it sends (the device code works identically).

Great! This will help - I’ll spend some time with this. I will likely create an ILI9341 interface first. I am likely to work with the LVGL UI library and an onscreen keyboard even though its not a great interface. I should follow up with the Q10 keyboard and a more portable form factor afterwards.

First struggle, most likely due to my lack of experience outside the Arduino sandbox.
When trying to include external, platformio libraries such as adding the following in main.c:

#include “lvgl.h”
#include “TFT_eSPI.h”

The compiler starts complaining about ambiguous functions, e.g.:

src/main.cpp:119:19: error: reference to ‘map’ is ambiguous
data->point.x = map(x, TS_MINX, TS_MAXX, 0, tft.width());

Sole question I have here is whether this is expected? I get the funny feeling doing this includes the bulk of the standard libraries due to the external libraries including them from a different location then your project. Which if thats the case, sounds like I am in for a very long session of code porting…

That is not expected. Alas, I can’t give better advice remotely other than it sounds like two of the includes you added are both defining a function called map.

Fixed - or rather, hacked out by copying the function from the esp32 xtensa libs and giving it a unique name. Ugly but functional. I now have a touchscreen setup and ready to work on. What I think I initially want is a basic « IRC » style channel thread, line wrapped messages preceded by sender name. I couldn’t yet identify if you are storing message history (while running), nor how to access it. I imagine a system where clicking a sent message would show a list of recipients who confirmed receiving it, assuming the mesh already supports that.