Hi all.
I’m not a C++ programmer, but have been writing C programs since the early 80s. I’ve taken the class functions out of the TCA9555 class to create simple C functions, but other than that I’m following the logic sequence in the unphone.cpp example.
Everything seems to work, other than the HX8357 display. I can set font colours and sizes Etc, but all the text appears on the display mirrored.
Wondered if anyone else has ever had this issue and if so, could they provide a steer as to what I might be doing wrong ?
Tks in advance
Hello!
The library is patched IIRR, are you sure you have our version?
Hamish, thanks for bothering to reply.
The steer about library patches is useful. Thanks, but I believe I’m using the right one. In the end I looked at the data sheet for the display driver and compared it to the Adafruit HX8357 library. Screen rotation seems to also require font rotation and that’s where the issue is (MADCTL_MY, MX and MV). I’ve now got it working with my own patch, which brings me to my point…
I like the hardware you and your team have produced, It should appeal to the “Tinkerers”, “ESP” and “Arduino” folk, but I don’t believe your software examples match that commercial quality. For me, a good example of this issue is demonstrated in “unphone.cpp”. Within it, you mask straight forward calls (for example, Serial.printf, you’ve substituted with “D”). This starts to make the example code write-only, because nobody want’s to pick things like that appart. In the ESP32 world, Serial.printf is a generally understood call. Why make it so difficult?
Sorry - Trying to be constructive, but the problem is exemplified by your quick reply. IIRR means International Institute of Rural Reconstruction to me… Whatever you meant by it, it’s hardly a suitable reply for someone seeking guidance on the use of a commercial product.
Regards
If I Remember Rightly (and it seems that I don’t, in this case) IIRR was a common contraction in this type of context, but then I’m a bit longer in the tooth than I used to be, and times move on
Thanks for your comments. The “D” macro is (or more likely was) a fairly common type of thing specifically for debugging in C/C++. A macro is not the same as a function call (like Serial.printf), as it is not necessarily present at compile time. I.e. the cpp preprocessor gives an opportunity to remove unwanted (debug) code before the cc (or gcc in our case) step runs. I suspect that with modern optimising compilers this doesn’t make much difference, but nevertheless it is an idiom I’ve come across before…
And if we’re going to be modern, then an IDE like VSCode will show you the definition of a macro without any effort – apart from configuring the beast in the first place – I prefer vi myself
Like many things the unPhone library suffered somewhat in the pandemic, and the subsequent component shortages (firstly due to closed factories, and then later the advent of hoarding as a competitive strategy). But like other open source projects there’s always the chance that a community will form around it and make contributions back to the codebase to solve problems like yours 
Glad you got it working, H
Again, thank you for your reply.
We could bat’n ball about being long in the tooth and macros, class members Etc, but in this forum that’s probably unproductive. If you want community take up, then perhaps your next project should be bringing your libraries up to scratch. When you look at (say) the M5Stack libraries, I think that’s what people expect to see these days. As a simple example, it would be nice to see a “HellowWorld.cpp” that highlights the use of the TCA9555 and the display driver. Something that would encourage the Tinkerers to get tinkering. My guess is, unphone.cpp is off putting to folk in the 16-30 age bracket who just want to get into IOT. My pennies worth and probably not worth much more…
You’re right of course but life is finite 
and I’ve the next iteration of the course to start working on… I’m hoping that when the new Meshtastic UI matures it will give a boost to unPhone programming, but in the meantime any contributions to the codebase would be very gratefully received as PRs on the git repository
All the best, Hamish
Perhaps you could facilitate that somehow? Maybe set up a forum category specifically for folk to provide links to their own unphone Github repositories? I bought the device to use as a UDP monitor for displaying diagnostics from my esp32 cluster. Eventually I plan to boot different firmware images off the SD card to make it more general purpose. I’m convinced that having some sort of forum with links to similar projects would aid sales and exposure.
Great idea! I think the way to start that would be to post a new thread on this forum? One thing to note at present is that due to supply problems the number of units out in the wild is still pretty small…
Hi Hamish.
Yeah, I think that’s a good plan. If you do that, I’ll contribute my own poorly conceived pennies worth.
IMO, the hardware combi is good and it needs promotion. Having said that, if you ever decide to bring out a new version, I’ve a few ideas that could possibly make it more attractive to the general public. If/when you decide to make more of the design, then feel free to drop me a line.