helping bring a new touch panel to meshtashtic

[steel robin]

Here we can chat without clogging up the channels

[ripe quartz]

@steel robin got the variant.h/.cpp files started for the CYD_TFT variant using your unphone as a guide. came across a file I couldnt locate. aka "unPhone.h" ... off the top of your head do you remember where its located?

was unPhone.h possibly meant to be the variant.h file?

[steel robin]

Hi and unPhone.h is our own library we've developed over the last few years - it provides a number of helpful functions. Most boards won't have such a library and so we need to put all the pieces together ourselves. Also don't worry about a variant.cpp either just yet

[mossy lintel]

so for this rgb led code can I just flash any old esp32 based board and wire up an led for testing ?

[ripe quartz]

nifty.... i should be ordering the 2.4 inch CYD and the rylr Lora module i plan on using on the first kinda stoked to tinker with it

been trying to do as much research as my mind can handle at one time to make it all make sense

[steel robin]

Yes - just firstly goto the variant.h for that board and add in the pin defines, compile, flash and enable external notifications

[steel robin]

Ok I hope it arrives soon - we'll be using your hardware to test on as I don't have one

[ripe quartz]

been looking into a library for an on screen keyboard to be able to call up for messaging. i know the device has one on stock firmware (doubt it will carry over though)

im considering throwing a CYD_TFT_2_4.md file into the mix for documenting the pin out

@steel robin the src code for mt does require arduino src code as well correct?

i see ardunio.h in the includes

im dumb

lol

[steel robin]

I think the ardiuno.h gets included in platformio builds as well by default

[steel robin]

If you are thinking about an on screen keyboard you should def checkout the #mui channel as I think there has been quite a lot of discussions there and some things in development already, not sure of the details but would be a shame to duplicate work etc if there is almost a solution comming in from elsewhere

[ripe quartz]

im doing many many hours of research trying to find everything possible before diving in

took a few days to learn some concepts i wasnt familiar with EE wise

now im learning more

[steel robin]

Cool beans! I think adding support for the screen will be easier than an on screen keyboard

[ripe quartz]

when you pulled the specs for the dev board the other day what data source did you happen to use?

trying to consolidate data into documentation

[steel robin]

Thats one of the things with the cheap stuff, no proper datasheets... I think I got it from a random shop

[ripe quartz]

oof

welllll for the 2.8 inch micro-usb variant there is decent documentation via https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display

[steel robin]

that name rings a bell, good find

but its a slightly different model?

[ripe quartz]

than the one i plan on using yes

pinout is siimilar

[steel robin]

ok well sounds promising

[ripe quartz]

someone in the discussions on that repo threw some code at the tft enabling problem

Arduino IDE.....use TFT_eTouch.h

#include <TFT_eTouch.h>

#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); //define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);```

[steel robin]

so in meshtastic already there are two different libraries used for screen and touch, the lovyan and TFT_eSPI so being able to reuse one is great

I tried both and prefered the other one for some reason can't remember exactly why

[ripe quartz]

im guessing TFT_eSPI is a #include in TFT_eTouch.h

havent grabbed the library yet just chilling reading some things

[ripe quartz]

OOP wins

the entire methodology of functions/methods and libraries just played out IRL

[ripe quartz]

delving deeper into the TFT etouch library discovered it wasnt on platformio, secondary problem, the CYD currently is unsupported by platformIO.

[steel robin]

Checkout the lovyan library - it works with platformio https://github.com/lovyan03/LovyanGFX

[ripe quartz]

@steel robin

#ifndef _VARIANT_CYD_ESP32_TFT
#define _VARIANT_CYD_ESP32_TFT

#include <TFT_eTouch.h>
// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); //define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);

//display section

#define TFT_DC 2
#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21


//LoRa Section
#define LORA_RX     //TODO: pinout
#define LORA_TX     //TODO: pinout


// hardware section

#define BOOT 0 

unsure where to go from here beyond "supporting the board in platform io "

stilll waiting to get the actual board because "poor guy lyfe"

[ripe quartz]

also here is tentative platformIO.ini file

[env:cyd2432]
platform = espressif32
board = esp32-s3-devkitm-1
framework = arduino
lib_ldf_mode = deep+
monitor_filters = esp32_exception_decoder
monitor_speed = 115200
upload_speed = 460800
board_build.partitions = min_spiffs.csv
build_flags =-DILI9341_2_DRIVER
-DTFT_WIDTH=240
-DTFT_HEIGHT=320
-DTFT_MISO=12
-DTFT_MOSI=13
-DTFT_SCLK=14
-DTFT_CS=15
-DTFT_DC=2
-DTFT_RST=-1
-DTFT_BL=27
-DTFT_BACKLIGHT_ON=HIGH
-DTFT_BACKLIGHT_OFF=LOW
-DTOUCH_CS=-1
-DLOAD_GLCD
-DSPI_FREQUENCY=55000000
-DSPI_READ_FREQUENCY=20000000
-DSPI_TOUCH_FREQUENCY=2500000
-DTFT_INVERSION_OFF

[steel robin]

I don't know what the process is to get an Arduino library working in platformio, why not use the lovyan library?

[ripe quartz]

arduino libs are supported it just has to be added

too new to know the steps

iam

[mossy lintel]

all you need to do is add a lib_dep line in teh platformio with a link to the github repo like this :

lib_deps =
  jgromes/RadioLib@^6.4.0
  https://github.com/meshtastic/esp8266-oled-ssd1306.git#ee628ee6c9588d4c56c9e3da35f0fc9448ad54a8 ; ESP8266_SSD1306
  mathertel/OneButton@^2.5.0 ; OneButton library for non-blocking button debounce
  https://github.com/meshtastic/arduino-fsm.git#7db3702bf0cfe97b783d6c72595e3f38e0b19159
  https://github.com/meshtastic/TinyGPSPlus.git#f9f4fef2183514aa52be91d714c1455dd6f26e45

[ripe quartz]

all the repos involved or just the ones I personally used?

hate life right now

lol

[mossy lintel]

post your full ini file. sounds like a syntax error.

[ripe quartz]

[env:cyd2432]
platform = espressif32
board = esp32-s3-devkitm-1
framework = arduino
lib_ldf_mode = deep+
lib_deps= https://github.com/meshtastic/meshtastic
https://github.com/achillhasler/TFT_eTouch


monitor_filters = esp32_exception_decoder
monitor_speed = 115200
upload_speed = 460800
board_build.partitions = min_spiffs.csv
build_flags =-DILI9341_2_DRIVER
-DTFT_WIDTH=240
-DTFT_HEIGHT=320
-DTFT_MISO=12
-DTFT_MOSI=13
-DTFT_SCLK=14
-DTFT_CS=15
-DTFT_DC=2
-DTFT_RST=-1
-DTFT_BL=27
-DTFT_BACKLIGHT_ON=HIGH
-DTFT_BACKLIGHT_OFF=LOW
-DTOUCH_CS=-1

-DSPI_FREQUENCY=55000000
-DSPI_READ_FREQUENCY=20000000
-DSPI_TOUCH_FREQUENCY=2500000

for posterity heres the variant file

#ifndef _VARIANT_CYD24_ESP32_TFT
#define _VARIANT_CYD24_ESP32_TFT



#define DILI9341_2_DRIVER
#include <TFT_eTouch.h>
// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); // define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);

// display section

#define TFT_DC 2
#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21
#define TFT_WIDTH = 240
#define TFT_HEIGHT = 320
#define TFT_BACKLIGHT_ON = HIGH
#define TFT_BACKLIGHT_OFF = LOW
#define TOUCH_CS = -1

#define SPI_FREQUENCY = 55000000
#define SPI_READ_FREQUENCY = 20000000
#define SPI_TOUCH_FREQUENCY = 2500000

// LoRa Section
#define LORA_RX // TODO: pinout
#define LORA_TX // TODO: pinout

// hardware section

#define BOOT 0

#endif/*_VARIANT_CYD24_ESP32_TFT*/

@mossy lintel For context im doing all of this with documentation only no actual board in hand as of yet

[mossy lintel]

@ripe quartzso for the ini you need to indent for extra lines. so for the lib_deps should be ```ini
lib_deps = https://github.com/meshtastic/meshtastic
https://github.com/achillhasler/TFT_eTouch

same with build flags.

you can def do most of the work getting it compiling without the physical board.

[steel robin]

Seems like the board we are talking about is the ESP32-2432S024C as sold here: https://www.aliexpress.com/i/1005006182025099.html

Are you targeting the resistive or capacitive touch version?

[ripe quartz]

capacitive

also the lorawan module is the RYLR993_lite by REYAX

[steel robin]

Sorry seems that model number is for the 2.8 in one, this one ESP32-2432S024 is the 2.4 inch one https://www.aliexpress.com/item/1005005865107357.html

But hard to find info, maybe the touch is using cst820 graphics ili9341

Looks like a plain esp32 not esp32-s2 or s3

[ripe quartz]

the board should be here in like an hour/// if there is a way to check the IC for the graphics and touch let me know

[steel robin]

Yup, if you've got good eyesight then the chips should be marked

[ripe quartz]

nice

so short list of things to do: on arrival document all marked chips

[steel robin]

Have you got vsvode and platformio set up? Meshtashtic repo cloned?

[ripe quartz]

yes

i actually did a fork of the repo and cloned that

[steel robin]

Great, you might want to make a branch for the first lot of work and keep master clean

[mossy lintel]

also, any defines you put in variant.h can be removed from the -D section of the ini file.

[steel robin]

It looks like you might have based your files on an esp32-s3 board, I'd suggest finding an esp one and replacing what's different

[ripe quartz]

sorry about that im back had to run my bro to work

CH340C is the serial chip but thats the only one i can read

tried the phone as a magnifier too and it couldnt even focus

its soo beeper sized i love it

[steel robin]

Can you read any numbers from the board itself to confirm which one actually got delivered? And pleased to see you have hardware, makes developing for it easier 😁

[ripe quartz]

esp32-2432so24 confirmed

[steel robin]

So first thing let's see if we can identify the chip...

[ripe quartz]

wifi esp-wroom-32

[steel robin]

If you try flashing an esp32 based board meshtashtic to it, during the flashing process you should see something about chip id

Don't worry it won't work yet

Just want to find out which variant of esp32 you have

Also try esptool.py flash_id

You might need to add -p COM2 or whatever

Can you read markings like N4R2

[ripe quartz]

ive been so focused on writing the code i was like ill learn to falsh later

[steel robin]

Just plug it in and click on the bottom of platformio where it says auto to see the usb ports available

[ripe quartz]

not seeing auto... im on linux if that has anything to do with it

[steel robin]

ok that's much better!

anything with a tty at the start?

[ripe quartz]

i can get it to pull up serial monitor thru the mesh.flasher website

and theres like 30 tty

[steel robin]

yes sure, but we'll need to be flashing from platformio soon enough anyway...

ok so on linux, open a terminal and type sudo dmesg

the last few lines should say stuff about the new device (cyd) you plugged in, including a port if it got assigned one

[ripe quartz]

yes

looks like tty0

[steel robin]

which distro are you using btw?

[ripe quartz]

ubuntu

[steel robin]

I'd expect to see something like ttyUSB0 or ttyACM0

ah good old brltty

its a braile facility notorious for interfering with usb serial stuff, google how to remove it with sudo apt purge brltty or something like that

[ripe quartz]

sudo dpkg -P brltty
sudo apt-get remove brltty
sudo apt-get --purge autoremove

didnt work

sheeesh

[steel robin]

ok try this, but with sudo before each line:

sudo systemctl mask brltty-udev.service
systemctl stop brltty.service
systemctl disable brltty.service```

or maybe just as it is would work!

[ripe quartz]

so i power cycled

terminal looks diff

attached to ttyUSB0

and it didnt disconnect taht i saw

[steel robin]

ok that's odd but well done for working round it!

so in platformio, select USB0 as the port, and some other esp32 board for the env: bit

then click the upload button!

[ripe quartz]

im seeing auto now

lol

[steel robin]

think thats because there is now a sensible thing for it to auto on!

when the upload starts, we need to look at the first few lines before it starts to actually flash

[ripe quartz]

good enough?

[steel robin]

ok, so first lots of getting libraries, that won't happen again, then compilation, then flash. I missed the bit we need to see!

[ripe quartz]

what am i specifically looking for

[steel robin]

can you do it again, and after it finishes, scroll back to the bit just after it does linking, but before it does the uploading 10% 20% bit

[ripe quartz]

lemme know if i need to restart

[steel robin]

you are clicking the arrow not just the tick yes?

[ripe quartz]

the upload arrow

yes

[steel robin]

ok, I'm doing the same now to find out exactly which line we need to look at

btw I've found the m5stack core has both regular esp32 and your display driver. You should make a copy of their variant and platformio.ini and base your ones from that I think

esptool.py v4.5.1
Serial port /dev/ttyACM3
Connecting...
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz```

look for this bit what does yours say?

[ripe quartz]

just restarted

ill give it sec now

funny enough its reading as a tbeam

[mossy lintel]

here is a terminal command if you want to do it over and over without clicky clacking pio run -e unphone -t upload replace unphone with whatever one you want (tbeam, cyd2432)

tbeam is the default environment, it might be compiling tbeam actually.

[steel robin]

Ah yes I haven't used the pio command line much thanks!

[ripe quartz]

it failed and i accidently closed the terminal running again to see the reason

[mossy lintel]

build, upload,monitor all in one command pio run -e tbeam -t upload && pio device monitor -e tbeam --baud=115200

[steel robin]

They move port sometimes

[mossy lintel]

at least it compiled

it shoudln't say tbeam though

[steel robin]

True it's a major milestone

[mossy lintel]

it should say cyd2432

[mossy lintel]

unless your modifying tbeam environment for you device.

[ripe quartz]

i actually deleted the cyd folder to get it back to factory

[mossy lintel]

ah ok.

that obsolete message using v4.3 seems really old, might not support new platformio options me thinks.

[steel robin]

Maybe you need to open a platformio terminal not a bash one?

[mossy lintel]

yeah, there is a little button to launch a pio terminal

[ripe quartz]

ok so idea

tbeam is the default in pio

[mossy lintel]

at the bottom,

[ripe quartz]

same issue in pio terminal

tbeam seems to be failing

should i make a cyd24 branch and delete all the things it says to remove?

and throw my cyd folder in the branch

[mossy lintel]

this is the clean main repo that is failing right now ?

[ripe quartz]

i can clone it again

maybe i messed something up im not seeing

[mossy lintel]

yeah try that first. Then maybe reinstall PIO because the old core message is troubling.

4.0 is from 2019

[steel robin]

so yes, I'd say make a new branch from your freshly cloned fork for the cyd24

in that, try to compile just for default.

then create your variant folder and variant.h and platformio.ini from m5core copies

switch to that enviornment and try to compile again, after customising those 2 files from https://meshtastic.org/docs/development/firmware/build/ like PRIVATE_HW stuff

[ripe quartz]

7 minutes in and still compiling

[steel robin]

if it suceeds it will cache most of the library stuff at least

for that environment!!

[ripe quartz]

Lol

failed

[steel robin]

ok so what's the red lines saying?

[steel robin]

ok no worries, it compiled just couldnt find your device. Switch to your new environment click on the bottom where it says default (firmware)

[ripe quartz]

yea

the new ini file based on the m5 stack

renamed the env:CYD24 right?

[steel robin]

so if you make a new variant and the files in it there should appear a new environment

renamed as in selected a different one?

[ripe quartz]

copied the ini file over to a cyd 24 folder and wrote in env: CYD24

[steel robin]

sounds cromulent

does it compile in this environment?

[ripe quartz]

unknown

about to test

went to smoke first

lol

[steel robin]

a full compile is almost long enough for me to smoke one on my old lappy!

[ripe quartz]

it failed but compiled for about 3 mins

hw-vendor threw three errors

[steel robin]

Ok check your new platformio.ini follows the guidance on building custom firmware

   ${esp32_base.build_flags} -D PRIVATE_HW -I variants/cyd24```

or better

    -D PRIVATE_HW
    -I variants/cyd24```

I mean, they are the same but readabilty really counts in a complex project like this

[ripe quartz]

it is compiling

we will see

[steel robin]

Perhaps you named your directory CYD24 and told platformio.ini it was called cyd24?

best to use lower case like the others prob

[ripe quartz]

[env:CYD24]
extends = esp32_base
board = m5stack-core-esp32
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter =
${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
-D PRIVATE_HW
-I variants/cyd24
-D ILI9341_DRIVER
-D CYD24
-D USER_SETUP_LOADED
-D TFT_SDA_READ
-D TFT_DRIVER=0x9341

-D DISABLE_ALL_LIBRARY_WARNINGS
-D HW_VENDOR= DIYmalls
lib_ignore =
m5stack-core
lib_deps =
${esp32_base.lib_deps}
lovyan03/LovyanGFX@^1.1.8

i will brb i need to rtun an errand

[steel robin]

ok, when you're back, I would change the top line to
[env:cyd24]
and then rename the directory CYD24 to cyd24

Found this really useful repo: https://github.com/rzeldent/platformio-espressif32-sunton

it's got a board.json for us! that's gonna save a ton of work: https://github.com/rzeldent/platformio-espressif32-sunton/blob/main/esp32-2432S024C.json

[ripe quartz]

@steel robin im back

awesome

[steel robin]

so goto that most recent link, download the raw file and save it into the boards directory

then change your platoformio.ini
board = m5stack-core-esp32

and take out the

  m5stack-core```

[ripe quartz]

k

[steel robin]

also comment out this line, we want to see warnings at this stage!
-D DISABLE_ALL_LIBRARY_WARNINGS

like this: ;-D DISABLE_ALL_LIBRARY_WARNINGS

[ripe quartz]

[env:cyd24]
extends = esp32_base
board = m5stack-core-esp32
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter = 
  ${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
    -D PRIVATE_HW
    -I variants/cyd24
  -D ILI9341_DRIVER
  -D cyd24
  -D USER_SETUP_LOADED
  -D TFT_SDA_READ
  -D TFT_DRIVER=0x9341
  
  ;-D DISABLE_ALL_LIBRARY_WARNINGS
  -D HW_VENDOR= DIYmalls

lib_deps = 
  ${esp32_base.lib_deps}
  lovyan03/LovyanGFX@^1.1.8

[steel robin]

also delete these for now:

  -D CYD24
  -D USER_SETUP_LOADED
  -D TFT_SDA_READ
  -D TFT_DRIVER=0x9341```

[ripe quartz]

#ifndef cyd24_H
#define cyd24_H

#include <TFT_eTouch.h>
// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); // define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);

// display section

#define TFT_DC 2
#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21
#define TFT_WIDTH = 240
#define TFT_HEIGHT = 320
#define TFT_BACKLIGHT_ON = HIGH
#define TFT_BACKLIGHT_OFF = LOW
#define TOUCH_CS = -1
#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5
#define HAS_TOUCHSCREEN 1
#define SCREEN_TOUCH_INT 16
// #define TOUCH_UART_PORT  //TODO:
// #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check
#define SPI_FREQUENCY = 55000000
#define SPI_READ_FREQUENCY = 20000000
#define SPI_TOUCH_FREQUENCY = 2500000

// LoRa Section
#define LORA_RX // TODO: pinout
#define LORA_TX // TODO: pinout

// hardware section

#define BOOT 0

#endif /*CYD24_H*/```

[steel robin]

actually leave the CYD24 in, could be useful

So look, if you really want to use the eTFT library over the Lovyan one, then at least say why

[ripe quartz]

only because it was recommeded by the people on the esp32 git

i have no other reasoning

[steel robin]

Well I've given you my reasoning for choosing it several times!!

[ripe quartz]

i guess i also havent dived into the lovyan

[steel robin]

so you have dived into the eTFT?

[ripe quartz]

i have

a bit

like 3 hours

[steel robin]

ok well lets go with that, I will learn more this way!

[ripe quartz]

i have attempted to remove the eTouch lib and just #include the eSPI lib and it threw an error on me

figured someone smarter could see if it would work on their end

[steel robin]

yes seems like the eTFT library doesn't support your touchscreen (lovyan does)

so we'll have to use something else...

[ripe quartz]

k guide me gwizz the jedi masta

[steel robin]

ok so I've had a quick look, and no other device in meshtastic has a seperate touch driver, so that's another level of complication

but touch isn't really used much yet I think

So if we use pre-existing screen definition we can get something in a few min I think

[ripe quartz]

#ifndef cyd24_H
#define cyd24_H

//#include <TFT_eTouch.h>
#include <SPI.h>
#include <Adafruit_SPITFT.h>
#include <LGFX_TFT_eSPI.hpp>

// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); // define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);
//^^^error here 

// display section

#define TFT_DC 2
#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21
#define TFT_WIDTH = 240
#define TFT_HEIGHT = 320
#define TFT_BACKLIGHT_ON = HIGH
#define TFT_BACKLIGHT_OFF = LOW
#define TOUCH_CS = -1
#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5
#define HAS_TOUCHSCREEN 1
#define SCREEN_TOUCH_INT 16
// #define TOUCH_UART_PORT  //TODO:
// #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check
#define SPI_FREQUENCY = 55000000
#define SPI_READ_FREQUENCY = 20000000
#define SPI_TOUCH_FREQUENCY = 2500000

// LoRa Section
#define LORA_RX // TODO: pinout
#define LORA_TX // TODO: pinout

// hardware section

#define BOOT 0

#endif /*cyd24_H*/```

intellisense gets all the credit here

[steel robin]

ok so in your variant.h put this:

  -D TFT_MISO=19
  -D TFT_MOSI=23
  -D TFT_SCLK=18
  -D TFT_CS=14
  -D TFT_DC=27
  -D TFT_RST=33
  -D TFT_BL=32
  -D SPI_FREQUENCY=40000000
  -D SPI_READ_FREQUENCY=16000000```

but instead of those pin numbers, put the ones for your board...

hang on

[ripe quartz]

if they are defined in the variant file is it required in th eini file?

[steel robin]

   -D TF_SPI_MOSI TFT_MOSI
   -D TF_SPI_SCLK TFT_SCLK
   -D TF_SPI_MISO TFT_MISO```

[steel robin]

no only once

[steel robin]

and more:

   -D TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
   -D TFT_BL```

hang on I got that wrong

[steel robin]

   -D TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
   -D TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
   -D TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
   -D TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
   -D TFT_BL GPIO_BCKL```

replace previous with that

And add some more!

sorry! you should be putting all this in variant.h and instead of -D you say #define

add in

#define SPI_READ_FREQUENCY 16000000```

[ripe quartz]

#ifndef cyd24_H
#define cyd24_H

//#include <TFT_eTouch.h>
#include <SPI.h>
#include <Adafruit_SPITFT.h>
#include <LGFX_TFT_eSPI.hpp>

// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); // define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
//TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);
//^^^error here 

// display section

#define TFT_DC 2
#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21
#define TFT_WIDTH = 240
#define TFT_HEIGHT = 320
#define TFT_BACKLIGHT_ON = HIGH
#define TFT_BACKLIGHT_OFF = LOW
#define TOUCH_CS = -1
#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5
#define HAS_TOUCHSCREEN 1
#define SCREEN_TOUCH_INT 16
// #define TOUCH_UART_PORT  //TODO:
// #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check
#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 16000000
#define SPI_TOUCH_FREQUENCY = 2500000
#define  TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
#define TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
#define  TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
#define  TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
#define TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
#define TFT_BL GPIO_BCKL
  
// LoRa Section
#define LORA_RX // TODO: pinout
#define LORA_TX // TODO: pinout

// hardware section

#define BOOT 0

#endif /*cyd24_H*/```

i still need to comment out the etouch stuff

[steel robin]

and

#define TFT_BUSY -1```

comment all the first bit for now:

#define TFT_MISO 12
#define TFT_MOSI 13
#define TFT_SCK 14
#define TFT_CS 15
#define TFT_BL 21
#define TFT_WIDTH = 240
#define TFT_HEIGHT = 320
#define TFT_BACKLIGHT_ON = HIGH
#define TFT_BACKLIGHT_OFF = LOW
#define TOUCH_CS = -1```

comment this as well!

#include <SPI.h>
#include <Adafruit_SPITFT.h>
#include <LGFX_TFT_eSPI.hpp>

// touch section
#define ETOUCH_MOSI 32
#define ETOUCH_MISO 39
#define ETOUCH_SCK 25
#define ETOUCH_CS 33
#define ETOUCH_IRQ 0xff // not used in this sketch

SPIClass hSPI(HSPI); // define SPI port to be used by TFT_eTouch

TFT_eSPI tft = TFT_eSPI();
//TFT_eTouch<TFT_eSPI> touch(tft, ETOUCH_CS, ETOUCH_IRQ, hSPI);
//^^^error here```

[ripe quartz]

done

what now

you did see the platformio file is throwing an error as well right

[steel robin]

So maybe post that file here?

[ripe quartz]

Sec grabbing a drink and cig

[steel robin]

me too! and soon after I will have to go and sleep...

[ripe quartz]

So at the moment we're implementing just the graphics correct?

Or is touch involved here as well

[steel robin]

no just touch for the minute

i mean just screen!

[ripe quartz]

lol

k

thought as much

[steel robin]

did you rename directory CYD24 to cyd24?

[ripe quartz]

yes

[steel robin]

the main firmware has a section for your screen we're re-using but touch will need a new bit of code in there

[ripe quartz]

[env:cyd24]
extends = esp32_base
board = m5stack-core-esp32
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter = 
  ${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
    -D PRIVATE_HW
    -I variants/cyd24
 
    -D cyd24
   

  ;-D DISABLE_ALL_LIBRARY_WARNINGS
  -D HW_VENDOR= DIYmalls

lib_deps = 
  ${esp32_base.lib_deps}
  lovyan03/LovyanGFX@^1.1.8```

[steel robin]

ok you need to download that json file and change your board= to match

and try compiuling!

[ripe quartz]

still throwing on line one

no section esp32_base

[steel robin]

and your folder is def called cyd24?

[ripe quartz]

yes

[steel robin]

hmm. show me the error again pls?

[steel robin]

and does it fail to compile? those red lines aren't always accurate

[ripe quartz]

yea it failed

[steel robin]

looking at the folder list on the left, it looks to me like you've still got capitals in the folder name?

[ripe quartz]

look at the first pic

lol

the error pic was older

cyd24 is no longer a valid env

hmmm

[steel robin]

try doing a clean and recompiling

or even close and restart vscode

[steel robin]

yes vscode looks confused, try restarting it

[ripe quartz]

it was i fixed the wrong env name

i forgot to change it in the meshtastic platform ini file

[steel robin]

have you got the esp32-2432S024C.json file in your boards directory?

and the case needs to match like board=esp32blahblah

[ripe quartz]

yes

[steel robin]

can you post your platformio.ini again pls?

I need to go now, feel free to post questions etc and I'll try to answer them in the morning!

[ripe quartz]

[env:cyd24]
extends = esp32_base
board = esp32_2432S024C
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter = 
  ${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
    -D PRIVATE_HW
    -I variants/cyd24
 
    -D cyd24
   

  ;-D DISABLE_ALL_LIBRARY_WARNINGS
  -D HW_VENDOR= DIYmalls

lib_deps = 
  ${esp32_base.lib_deps}
  lovyan03/LovyanGFX@^1.1.8```

[ripe quartz]

ok before i pass out heres where i got to.

[env:cyd24]
extends = esp32_base
platform= espressif32
board = esp32-2432S024C
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter = 
  ${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
    -D PRIVATE_HW
    -I variants/cyd24
 
    -D cyd24
   

  ;-D DISABLE_ALL_LIBRARY_WARNINGS
  -D HW_VENDOR= DIYmalls

lib_deps = 
  ${esp32_base.lib_deps}
    lovyan03/LovyanGFX@^1.1.8
    bodmer/TFT_eSPI @ ^2.5.43
    paulstoffregen/XPT2046_Touchscreen @ 0.0.0-alpha+sha.26b691b2c8```

#ifndef cyd24_H
#define cyd24_H

#include <SPI.h>
#include <TFT_eSPI.h>
#include <XPT2046_Touchscreen.h>

TFT_eSPI tft = TFT_eSPI();

// Touchscreen pins
#define XPT2046_IRQ 36  // T_IRQ
#define XPT2046_MOSI 32 // T_DIN
#define XPT2046_MISO 39 // T_OUT
#define XPT2046_CLK 25  // T_CLK
#define XPT2046_CS 33   // T_CS

SPIClass touchscreenSPI = SPIClass(VSPI);
XPT2046_Touchscreen touchscreen(XPT2046_CS, XPT2046_IRQ);

#define SCREEN_WIDTH 320
#define SCREEN_HEIGHT 240
#define FONT_SIZE 2

// display section

// #define TFT_DC 2
// #define TFT_MISO 12
// #define TFT_MOSI 13
// #define TFT_SCK 14
// #define TFT_CS 15
// #define TFT_BL 21
// #define TFT_WIDTH = 240
// #define TFT_HEIGHT = 320
// #define TFT_BACKLIGHT_ON = HIGH
// #define TFT_BACKLIGHT_OFF = LOW
// #define TOUCH_CS = -1
#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5
#define HAS_TOUCHSCREEN 1
#define SCREEN_TOUCH_INT 16
// #define TOUCH_UART_PORT  //TODO:
// #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check
#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 16000000
#define SPI_TOUCH_FREQUENCY = 2500000
#define TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
#define TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
#define TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
#define TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
#define TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
#define TFT_BL GPIO_BCKL
#define TFT_RST ILI9341_DEV_CONFIG_RESET_GPIO_NUM
#define TFT_BUSY -1

// LoRa Section
#define LORA_RX 35 // TODO: pinout
#define LORA_TX 22 // TODO: pinout
#define LORA_RST 21
// hardware section

#define BOOT 0

#endif /*cyd24_H*/```

[steel robin]

Try

#ifndef cyd24_H
#define cyd24_H

//#include <SPI.h>
//#include <TFT_eSPI.h>
//#include <XPT2046_Touchscreen.h>

//TFT_eSPI tft = TFT_eSPI();

// Touchscreen pins
//#define XPT2046_IRQ 36  // T_IRQ
//#define XPT2046_MOSI 32 // T_DIN
//#define XPT2046_MISO 39 // T_OUT
//#define XPT2046_CLK 25  // T_CLK
//#define XPT2046_CS 33   // T_CS

//SPIClass touchscreenSPI = SPIClass(VSPI);
//XPT2046_Touchscreen touchscreen(XPT2046_CS, XPT2046_IRQ);

#define SCREEN_WIDTH 320
#define SCREEN_HEIGHT 240
#define FONT_SIZE 2

// display section

// #define TFT_DC 2
// #define TFT_MISO 12
// #define TFT_MOSI 13
// #define TFT_SCK 14
// #define TFT_CS 15
// #define TFT_BL 21
// #define TFT_WIDTH = 240
// #define TFT_HEIGHT = 320
// #define TFT_BACKLIGHT_ON = HIGH
// #define TFT_BACKLIGHT_OFF = LOW
// #define TOUCH_CS = -1
#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5
//#define HAS_TOUCHSCREEN 1
//#define SCREEN_TOUCH_INT 16
// #define TOUCH_UART_PORT  //TODO:
// #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check
#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 16000000
#define SPI_TOUCH_FREQUENCY = 2500000
#define TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
#define TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
#define TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
#define TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
#define TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
#define TFT_BL GPIO_BCKL
#define TFT_RST ILI9341_DEV_CONFIG_RESET_GPIO_NUM
#define TFT_BUSY -1

// LoRa Section
#define LORA_RX 35 // TODO: pinout
#define LORA_TX 22 // TODO: pinout
#define LORA_RST 21

#endif /*cyd24_H*/```

And your touchscreen is using CST816 not XPT2046 you won't need those libraries / defines

[ripe quartz]

Oh nice

so there is a CST816 library

on platIO

[steel robin]

Yes but also it's supposedly supported by lovyan

So using just one would be better especially as lovyan is already used for most screens in meshtashtic. In the medium term all the screen display stuff will get completely rewritten. We want this new display to be just another one that gets ported to the new system, rather than the odd one out that might get left out especially as it's likely to be uncommon

[ripe quartz]

ah ok

taht makes sense

are you able to continue today like we did yesterday?

so using the lovyan lib how should i go about defining the touch pins?

i referred to this repo for pin id https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display/blob/main/PINS.md

[steel robin]

Well, the json file we found for this board already gives us all the pins.

so we can just #define them in the variant.h to match the names that meshtastic expects.

[ripe quartz]

like so ?```cpp// Touchscreen pins
#define CST816S_IRQ 36 // T_IRQ
#define CST816S_MOSI 32 // T_DIN
#define CST816S_MISO 39 // T_OUT
#define CST816S_CLK 25 // T_CLK
#define CST816S_CS 33 // T_CS

or is the I2Cpart needed as well

like

#define CST816S_I2C_IRQ 36  // T_IRQ
#define CST816S_I2C_MOSI 32 // T_DIN
#define CST816S_I2C_MISO 39 // T_OUT
#define CST816S_I2C_CLK 25  // T_CLK
#define CST816S_I2C_CS 33   // T_CS

there is a section of the json that looks like

"'-D TOUCH_CST816S_I2C'",
      "'-D CST816S_IO_I2C_CONFIG_DEV_ADDRESS=CST816S_IO_I2C_CONFIG_DEV_ADDRESS_15'",
      "'-D CST816S_I2C_HOST=I2C_NUM_0'",
      "'-D CST816S_I2C_CONFIG_SDA_IO_NUM=33'",
      "'-D CST816S_I2C_CONFIG_SCL_IO_NUM=32'",
      "'-D CST816S_I2C_CONFIG_SDA_PULLUP_EN=GPIO_PULLUP_ENABLE'",
      "'-D CST816S_I2C_CONFIG_SCL_PULLUP_EN=GPIO_PULLUP_ENABLE'",
      "'-D CST816S_I2C_CONFIG_MASTER_CLK_SPEED=400000'",
      "'-D CST816S_I2C_CONFIG_CLK_FLAGS=0'",```

leads me to believe we need the I2C part but unsure

using the unphone and tdeck as reference they actually dont define the touch pins

they just define HAS_TOUCHSCREEN 1

and unphone defines USE_XPT2046 ... im going to track down where this came from and see if there is a comparable for the cst816s

[steel robin]

I can tell you I introduced the USE_XPT2046 so that's unique to unphone

so the tdeck uses i2c and therefore doesn't need to define the pins

the unPhone has the touchscreen on the SPI bus so again, doesn't need to define the pins

But let's just get compiled with what we have so far, then flashed, then see if the screen works, then move on to touch?

[ripe quartz]

k

[steel robin]

So I've been wondering since late last night - does it compile yet??!

[ripe quartz]

compiling now for test

still going strong

4 mins in and still looking good

[steel robin]

yup i'd expect it to fail early doors with problems in platformio.ini or variant.h

[ripe quartz]

the variant.h got fixed when i woke up this morning

realized i didnt include lovyan

like in my sleep
i woke up like god im dumb

[steel robin]

best to put the mention in platformio as in

  lovyan03/LovyanGFX ```

[ripe quartz]

it did fail after 9 mins

[steel robin]

the actual #include is done in the firmware itself

[ripe quartz]

failed on this line -D HW_VENDOR= DIYmalls

[steel robin]

I think there is something extra not needed - try commenting it out with ;

[ripe quartz]

threw that line in because last time it failed from not having something there

[steel robin]

have you got a -D PRIVATE_HW

[ripe quartz]

yes

[steel robin]

so what error do you get if you comment out the DIYmalls line?

[ripe quartz]

still compiling

[steel robin]

k

[ripe quartz]

if it breaks it will break soon

is on src/lib26d

into the nimble now

its were it broke last time we find out here

couldnt open TTYUSB0

[steel robin]

ok busy for 20min

[ripe quartz]

so it compiled just cant actually link to the device yet

ok

[steel robin]

Right, that's great news!

ok so, device is plugged in , turned on, the port appears when its plugged in and disappears when removed?

[ripe quartz]

yes

[steel robin]

hmm

try following the guidance in yellow about udev rules

[ripe quartz]

random | i apparently palmed into the code

or my cig pack did when i tossed it down...lol

[steel robin]

I've had that a lot of time...

[ripe quartz]

im afvsc but mobile on tablet for a sec

So I added myself to the dial out group which s.o. recommended

[steel robin]

good one, forgot about that hurdle

logout to activate it

brb gotta go see a man about a dog

[ripe quartz]

with that change we have successful flash

no screen though sadly

did 2 power cycle tests with buttons one plug and unplug test as well still no screen

headway has been made though

now do we test other pins for the display or stick to the ones in the json file?

[steel robin]

no I think lets keep faith with that json for now

what do you see if you open serial monitor?

[ripe quartz]

failed to open ttyUSB1

0

srry

[steel robin]

has it changed port number?

[ripe quartz]

unknown

do i run sudo mesg again?

[steel robin]

do you prefer clicking or command line

[ripe quartz]

either depends on my mood

[steel robin]

so command line try dmesg

or sudo dmesg

[ripe quartz]

still failed to open

it is on ttyusb0

but wont open in monitor

[steel robin]

try reseting it?

sounds like you've still got problems, permissions etc

on the command line do

tio /dev/ttyUSB0```

[steel robin]

and this is the port that dmesg reports now?

and is there a reset button? if so press it whilst connected to serial?

[ripe quartz]

still showing up as usb0

ttyusb0

wth

no dialout group no tty group

found them

just reloaded to get perms

unsure of what to do here

tried to get perms and add mysefl to dialout and tty groups then reload and test the monitor

no connection

should i be using dmesg before every test

?

we are in

[steel robin]

sorry was away

good news!

[ripe quartz]

Posted for helping others

^^^

[steel robin]

that's great, but it might not survive a reboot...

[ripe quartz]

seems nothing occuring on the serial port atm

[steel robin]

what about during and after a reset?

of the device

[ripe quartz]

we have traffic

[steel robin]

well maybe... but we've got meshtastic booted! Whoop!!!

ok I've got friends round now so can't really help much more now

so things to think about maybe:
No I2C devices found during boot

screen doesn't seem to be reporting...

prob able to chat a bit later on tonight

[ripe quartz]

kk ive got work from 4om till midnightish its 1230 now

pm*

[steel robin]

to get some i2c devices found try adding this to variant.h:

#define I2C_SCL CST816S_I2C_CONFIG_SCL_IO_NUM```

[ripe quartz]

thinking ahead just getting the idea down::: keyboard on the dang thing i would like to think about a half key design where each button represents 2 letters/symbols. screen too small for fullsize keyboard. last option is T9 style (oldschool flip phone keyboard)

If(guiSkills){ chime in here}

alphabetical layout for halfkey seems best

[steel robin]

Hmm there was some chat about keyboard support recently - we would need to find an I2C keyboard controller

[ripe quartz]

Was researching a library last night as I went to sleep but lost the link

More of a touch app than hw keyboard

[ripe quartz]

https://github.com/GadgetFactory/CST816S_touchscreen/tree/main/components/CST816S_touchscreen

should we incorporate this lib

[ripe quartz]

Just checked it out during my break and I would say it is a bad fit

[ripe quartz]

@steel robin you up?

https://github.com/BrazenCodebane/firmware/tree/CYD24

current state pushed

[ripe quartz]

POSTERITY POST: for the project we added the following json file to the boards folder of the meshtastic firmware https://github.com/rzeldent/platformio-espressif32-sunton/blob/main/esp32-2432S024C.json

we then updated the PlatformIO.ini for the full project to default to the cyd24 environment.
we then wrote the following variant.h

#ifndef cyd24_H
#define cyd24_H

#include <LovyanGFX.hpp>

// display section
#define SCREEN_WIDTH 320
#define SCREEN_HEIGHT 240
#define FONT_SIZE 2

#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5

#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 16000000
#define SPI_TOUCH_FREQUENCY = 2500000
#define TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
#define TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
#define TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
#define TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
#define TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
#define TFT_BL GPIO_BCKL
#define TFT_RST ILI9341_DEV_CONFIG_RESET_GPIO_NUM
#define TFT_BUSY -1
#define I2C_SDA CST816S_I2C_CONFIG_SDA_IO_NUM // I2C pins for this board
#define I2C_SCL CST816S_I2C_CONFIG_SCL_IO_NUM
//#define I2C_DEV_ADDRESS CST816S_IO_I2C_CONFIG_DEV_ADDRESS
// #define HAS_TOUCHSCREEN 1
// #define SCREEN_TOUCH_INT 16
// #define USE_CST816S

//  #define TOUCH_I2C_PORT  //TODO:
//  #define TOUCH_SLAVE_ADDRESS 0x5D  //TODO:test and check

// LoRa Section
#define LORA_RX 35 
#define LORA_TX 22 
#define LORA_RST 21

#endif /*cyd24_H*/```

we then wrote up a platformIO.ini for the cyd24 variant

[env:cyd24]
extends = esp32_base
platform= espressif32
board = esp32-2432S024C
board_level = extra
monitor_filters = esp32_exception_decoder
build_src_filter = 
  ${esp32_base.build_src_filter}

build_flags = ${esp32_base.build_flags}
    -D PRIVATE_HW
    -I variants/cyd24
 
    -D cyd24
   

  ;-D DISABLE_ALL_LIBRARY_WARNINGS
  ;-D HW_VENDOR= DIYmalls

lib_deps = 
  ${esp32_base.lib_deps}
    lovyan03/LovyanGFX@^1.1.8

[ripe quartz]

@mossy lintel whats up

[mossy lintel]

nuttin much

[ripe quartz]

wanna work on the thing or you busy?

[mossy lintel]

just about to have dinner but I've got a few minutes. making any progress ?

[ripe quartz]

we have a multiple successful flashes but no screen

running into this error

0 I2C device found at address 0x15
0 Device found at address 0x15 was not able to be enumerated

any idea what it means?

google was no help

im also stupid

lol

enumeration normally means something along the lines of iterating through something right?

[mossy lintel]

each i2c device has a unique address. The display should have a unique address. could it be 0x15 ?

[ripe quartz]

yes it is at least according to the json file we are using

[mossy lintel]

ok, then possible the display is not wired up to the default i2c bus pins or maybe the display is not powered up. (guesses)

[ripe quartz]

what pin might i need to trigger to get the screen powered up?

TFT_BL?

[mossy lintel]

i'm not sure. Weird that the TFT has SPI pins and I2C pins. does it use both interfaces ?

[ripe quartz]

unsure

let me check the json

[mossy lintel]

wait. i think it's just the touch sensor that uses i2c.

[ripe quartz]

looks to me like the touch IC uses i2c while the tft itself uses spi

[mossy lintel]

the CST816S, yeah.

[ripe quartz]

yes

[mossy lintel]

gotta go to dinner. keep banging your head on it. But SPI can be tricky because esp32 have multipel SPI busses.

[ripe quartz]

"'-D ILI9341_SPI_HOST=SPI2_HOST'", in the json leads me to believe its the second spi bus

 
#define TFT_SPI_HOST ILI9341_SPI_HOST

heres my attempt

compiling to test

FAILED

#define TFT_SPI_HOST SPI2_HOST

second attempt

[steel robin]

I'm surprised that first version failed and then the second one didn't, they should be identical

[ripe quartz]

I realized the ttyusb0 serial had closed

Either should work

You were correct my hack to get it working won't last

Any chance you can take a look at the json and guide my brain to the next logical step

there wouldnt happen to be a way to pull everything from the json in with one command would there @steel robin

[steel robin]

Sorry I've not got much time today, but basically we have already got the JSON file included, that's what the board= line does in platformio.ini

It's progress that you got a device found but not enumerated, that shows I2C device touchscreen is recognised but we haven't coded support for it yet

One thing to try is backlight invert I'll try to get syntax in a couple of min

[steel robin]

try changing line 318 of graphics/TFTDisplay.cpp:
cfg.invert = false; // true to invert the brightness of the backlight
try it as true

[ripe quartz]

no change in device state

backlight did not engage
no picture

[steel robin]

When you restart device do you see any messages from [screen]?

Or Power to TFT Backlight

[ripe quartz]

no and no

[ripe quartz]

looking into the main file to learn more about it stumbled on this gem ```cpp
if (screen_found.port != ScanI2C::I2CPort::NO_I2C) {
switch (screenInfo.type) {
case ScanI2C::DeviceType::SCREEN_SH1106:
screen_model = meshtastic_Config_DisplayConfig_OledType::meshtastic_Config_DisplayConfig_OledType_OLED_SH1106;
break;
case ScanI2C::DeviceType::SCREEN_SSD1306:
screen_model = meshtastic_Config_DisplayConfig_OledType::meshtastic_Config_DisplayConfig_OledType_OLED_SSD1306;
break;
case ScanI2C::DeviceType::SCREEN_ST7567:
case ScanI2C::DeviceType::SCREEN_UNKNOWN:
default:
screen_model = meshtastic_Config_DisplayConfig_OledType::meshtastic_Config_DisplayConfig_OledType_OLED_AUTO;
}
}

thowing this snippet into the main file to see if it pops up in the serial monitor

oh im dumb screen_found isnt a bool so that wont work

[ionic hemlock]

The Sunton CYD is already supported by meshtastic device-ui lib as an add-on and connected via serial (UART, BT or WIFI) to any meshtastic LoRa board.
How does your scenario look like? Do you want to attach a LoRa chip to the CYD?

#mui message

[ripe quartz]

I have a rylr 993 lite Lora chip for it yes

[ionic hemlock]

But that's an UART chip, or?

[ripe quartz]

I do believe so

[ionic hemlock]

This won't be supported by meshtastic.

meshtastic only supports SPI

but you can use the RA-01SH, that's also tiny.

[ripe quartz]

link?

[ionic hemlock]

not sure if CYD has enough pins exposed, would need to solder directly to the processor pins.

https://www.aliexpress.com/item/1005003087292795.html

[ripe quartz]

limited to 12 pins is partially why i was going for a uart connection was not aware mt didnt support uart

actually less due to many pins crossing over between buses

how hard would it be to support UART in the ecosystem?

[ionic hemlock]

The RadioLib used by meshtastic does not support UART, and most likely will never support it due to its limited configuration capabilities of the SX12xx chipset.

[ripe quartz]

ok fixable issue. find new spi lora module fo rth project easy enough

any guidance on getting the screen to operate while running the meshtastic firmware?

at the moment the Lora module is disconnected anyway

[ionic hemlock]

There is nothing special needed to do this. Just fill out another LGFX class in TFTDisplay.cpp. That's all.

You can use this as a template:
https://github.com/meshtastic/device-ui/blob/master/include/LGFX_ESP2432S028RV1.h

[ripe quartz]

#ifndef cyd24_H
#define cyd24_H

#include <LovyanGFX.hpp>

// display section
#define ILI9341_2_DRIVER
#define TFT_WIDTH 320
#define TFT_HEIGHT 240
#define FONT_SIZE 2

#define TFT_OFFSET_X 0
#define TFT_OFFSET_Y 0
#define TFT_OFFSET_ROTATION 0
#define SCREEN_ROTATE
#define SCREEN_TRANSITION_FRAMERATE 5

#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 16000000
#define SPI_TOUCH_FREQUENCY = 2500000
#define ILI9341_SPI_HOST SPI2_HOST
#define TFT_CS ILI9341_SPI_CONFIG_CS_GPIO_NUM
#define TFT_MOSI ILI9341_SPI_BUS_MOSI_IO_NUM
#define TFT_MISO ILI9341_SPI_BUS_MISO_IO_NUM
#define TFT_SCLK ILI9341_SPI_BUS_SCLK_IO_NUM
#define TFT_DC ILI9341_SPI_CONFIG_DC_GPIO_NUM
#define TFT_BL GPIO_BCKL
#define TFT_RST ILI9341_DEV_CONFIG_RESET_GPIO_NUM
#define TFT_BUSY -1

[ripe quartz]

compiling now for above code

we shall see what happens

flash successful no screen activity yet

toggled cfg.invert to true re flashing

[ionic hemlock]

double check the pwm channel and frequency

check also reset pin (=-1 ?)

remove cfg.memory_xxxxxx

[ripe quartz]

would that info be in the json? im guessing it would be.

[ionic hemlock]

vscode has a good search function

(magnifier icon in the left icon bar)

[ripe quartz]

pwm was commented out

and cfg.memory is now commented out

was talking to one of my professors about the project and he said this "could you do a write up of what it is supposed to do along with sketches of the interface and the type of data it will be working with. That way I can get a big picture before I start having to look at any details."

[ionic hemlock]

you lost me... what is "it" and what interface?

[ripe quartz]

im guessing pinouts

"it" being the project itself

[ionic hemlock]

"it" is your project then? meshtastic on cyd?

[ripe quartz]

yes

self contained

no seperate meshtastic device

[ionic hemlock]

like the unphone

[ripe quartz]

yes but smaller scale

i jokingly call it the meeper

but i kindof like tha name now

[steel robin]

Hi

[ripe quartz]

hihi

speaking of @steel robin i saw the info that you did a lot of dev on the unphone

good job my dude

[steel robin]

Thanks! It's why I offered to help you, I've just done a similar job

[ripe quartz]

alrighty im going to commit the newest stuff to my cyd branch and link it so you guys can snag the code and take a look

[steel robin]

Mverc makes good points that next challenge will be to find a lora module and get it wired up. The cyd might not be super easy to wire into

[steel robin]

Cool I'll try to request contribution access to it if you like I can push changes (onto a new branch?)

[ripe quartz]

yes please

https://github.com/BrazenCodebane/firmware/tree/CYD24

[steel robin]

so first search results in suggest you have to invite others, so you can goto settings of your repository and then on the top of the left list is collaborators, my github username is garethhcoleman

[ripe quartz]

sent

[ionic hemlock]

btw: you also need to add the touch part to LGFX. No need for any other touch external library.

[ripe quartz]

ill take a look at the unphone section of the LGFX and see what i can borrow

im not seeing a CS pin for the touch in the json whats my next step

?

[ionic hemlock]

use that from the CYD specification and define it in variant.h

or put it also into the board json if you like

[ripe quartz]

ok so minor change the chip on the display chip is a cst820

i could see it in the bright sunlight

lol

[ionic hemlock]

so you dind't buy a real CYD, just a clone?

[ripe quartz]

no idea

amazon

lol

sunton documentation shows its a 920 as well

820*

[ionic hemlock]

This is the original CYD. If you use a clone then you'll have some problems you need to solve by yourself... trial and error.

[steel robin]

I think maybe the cst820 or is it 821 could be the touch controller chip

[ripe quartz]

20

I have work until midnightish. anyone going to be available in 6 hours
?

i am very excited to be making headway

[steel robin]

sorry I'll be asleep then!

But I've got some changes, one I think just might work, shall I push to your branch or make a new one?

[ripe quartz]

go ahead and push it

the branch doesnt work as it stands so its fine

[steel robin]

ok so mostly I tidied up sorry hope it's not too rude I just like things to look a certain way, feel free to add back anything

like pragma once rather than the ifndef at the start

but sig change might be ILI9341_DRIVER instead of ILI9341_2_DRIVER

[ripe quartz]

the 2 driver is the custom one in the LGFX

[steel robin]

because screen is only looking for the first one, then it creates a screen object with all the pins we've defined etc. so try that, then also try inverting the BL config line in TFDisplay cfg.invert = false; // true to invert the brightness of the backlight

[steel robin]

maybe, but if it doesn't match something in TFTDisplay then we'd need to write it from scratch.

where did you find the 2 driver reference?

[ripe quartz]

that is in the tftdisplay

i wrote it

or borrowed and modified

[steel robin]

Ah, ok but that function is at the end of the code, and earlier there are #ifdefs that contain the main functions. So because you weren't matching those ifdefs, the main functions needed weren't being declared

[ripe quartz]

did so to be able to change things without effecting the core of the code

[steel robin]

well in a way you suceeded

and it looks good

just in slightly the wrong place that's all!

[ripe quartz]

we can relocate it and it should be fine

[steel robin]

and also extend a couple of ifdefs

but if we compare your 2 version with the original, what real differences?

[ripe quartz]

was going to add the touch section of the unphone as a base and modify it to fit

i actually did that and then deleted the changes to pull your version

[steel robin]

sure, I looked at the other options and one of the others has an i2c touchscreen

which is more similar to yours than unphone

[ripe quartz]

Im still unsure wheether this vvariant is runnign spi for the display or i2c

goodness

[steel robin]

def spi I think

[ripe quartz]

that was fat finger central

lol

i think so as well

[steel robin]

i2c displays tend to be small

and all the stuff in the board.json is spi

[ripe quartz]

right

alright ive gotta get ready for work...

[steel robin]

but spose until we see an image....

speak soon

[ripe quartz]

yes ill slam my head against the wall some more when i get off

[steel robin]

Hey welcome to the glamorous and rewarding world of embedded development!!

[ripe quartz]

Academic programming versus real world is kinda nifty

Projects both take experimentation but real world has much less psuedocode

Lol

[ripe quartz]

ummmm head meet wall

[ripe quartz]

ouch brain hurts.. too much thinking and shuffling things around

i wanna cry it still doesnt work

check the repo for updates

[ionic hemlock]

I think this code won't even compile as there are undeclared variables. With the introduction of CST820 #defines it looks now completely broken as the CST820 is a touch controller and not a display controller. I suggest you first get more familiar with the CYD hardware and how things work before trying to implement something in the meshtastic project. There are lots of small CYD projects on github that help you getting the display running.
Also I sent you code to set pwm_channel = 7 but you used 1.

Furthermore, while experimenting, I suggest to reduce the SPI frequency to a much lower value, as the meshtastic firmware instructs the cpu to run at 80MHz instead of 240MHz.

[ripe quartz]

that code was a roughstarting point i cleaned it up before bed

also relocated it to the coreect place in the tft... file

current iteration

also attempted to declare a cst820 variable but seemed to me the lgfx variables are all part of a struct i couldnt find

[steel robin]

Hi! and all the lgfx stuff is in the library - i think it stands for Lovyan Graphics eFeXts

So we could take one of (at least) 2 approaches:
1 we create our own section for this display and touchscreen combo

2 we extend the existing section for our display so that we (and others) can optionally add a touchscreen to it

I'm a bit of a tree-hugger so let's try to recycle as much of the existing code as possible!!!

Also its a kinda cool challenge to try to implement maximum functionality with a few delicate but powerful changes to the code

sure we could wade in and add a whole heap of stuff, but how much more elegant to reach in, add a couple of IFs and THENs, and just quietly add another supported device

So I think the first step is to see if our display config in variant.h is getting through to the driver sections in TFTDisplay.h. We should be seeing something from LOG_INFO("Doing TFT init\n");

[ripe quartz]

Hi! Any chance you can walk me through the handshake process for the screen... At the moment all I understand is it's something like pin identification, bus id, handshake success. But I'm sure I'm missing something huge

[ripe quartz]

Chat GPT to the rescue

Here's a basic process of how handshaking occurs between the ESP32 and the TFT screen using SPI:

Initialization: First, both the ESP32 and the TFT screen need to be initialized. The ESP32 initializes its SPI interface and configures the communication parameters such as clock speed, data order, and mode. The TFT screen also initializes its SPI interface and prepares to receive commands and data.
Chip Select (CS): The ESP32 selects the TFT screen by asserting the chip select (CS) pin of the TFT screen. This indicates to the TFT screen that it should pay attention to the upcoming data or commands on the SPI bus. Typically, each SPI device has its own CS pin.
Command/Data Differentiation: The ESP32 sends commands or data to the TFT screen by transmitting bytes over the SPI bus. Typically, the first byte transmitted after selecting the device is a command byte, which tells the TFT screen what operation to perform (e.g., set pixel color, draw a line, etc.). Subsequent bytes may contain data associated with the command (e.g., color values).
Acknowledge: After receiving each command or data byte, the TFT screen acknowledges the receipt. This acknowledgment can be implicit (e.g., by properly processing the command or data) or explicit (e.g., by sending an acknowledgment byte back to the ESP32).
Transaction Completion: Once the ESP32 has finished sending all the necessary commands and data to the TFT screen for a particular operation (e.g., drawing an image), it deasserts the CS pin, indicating the end of the transaction.
Idle State: Both devices return to an idle state, ready for the next transaction.

[ripe quartz]

I agree but my methodology is slightly different.
write the code and be explicit in your needs then locate and recycle what you can once it works to reduce codebase

[steel robin]

Hiya! We say to our students "If you promise not to use chatGPT to write your homework, we'll promise not to use it to mark your homework!"

On this occasion I can't see any obvious hallucinations

We will hope that the library handles all the lower level stuff like handling the CS pin for us. Let's look at the structure of TFTDisplay.cpp. We can identify this as the important bit of code by looking for how another screen gets initialised.

Also this will give us clues about where we would need to patch in support for our new screen, whethere we make new code for it or try to reuse some. so lets look for ILI9341_DRIVER

So this reveals lots of interesting things. Firstly, and I've only just noticed this, it isn't defined in any variant.h apart from our one!!

That means that for some reason, support for this display was coded up but no actual meshtastic devices are using it!

which is odd

So we can completely 'take it over' if we wanted to.

But at least it's there. So it's found in main.cpp, images.h, screen.cpp, ScreenFonts.h, TFTDisplay.cpp, NodeDB.h and our variant

So if we follow the flow of the code, in main there is an IFDEF statement that basically says if we have a screen defined init it using function in screen.cpp

Then quite a few references in screen.cpp one of them calls TFTDisplay.cpp if the screen is a tft type

then the action happens there

the other refs in images.h and ScreenFonts.h are just to switch in large fonts, most of the screen.cpp refs are for that too, the NodeDB one just says we have a screen.

So our driver will need to be in all these places, just as an extension to the existing switches in most of them, but we'll have to do the real work in TFTDIsplay.cpp

The structure of TFTDisplay is a bit hard but once you realise its in two main bits and how the IFDEFs work it makes sense.

First 15 lines are for all displays, then we start having custom bits for each of the 6 displays the function handles. vscode lets you collapse these and then it is really clear whats going on at a high level:

After the initial bit, we have to switch our screen into the main bit starting at 493

So given that ILI9341_DRIVER isn't used and it's badly named, I propose your new screen is called ILI9341_CS and also that way we need one less define in our variant.h

So we could go round and just rename all instances of ILI9341_DRIVER with ILI9341_CS - or if you like we can add it alongside and remove the old one later

[ripe quartz]

ILI9341_CS works

also hello and good morning

[ripe quartz]

@steel robin done flashing now

@steel robin done flashing now to see if it works

[steel robin]

Hello! When you get a chance to push the changes you've made I can see them more easily

[steel robin]

and I don't know how I missed it, but the ILI9341 is used by m5stack-core so we cant just easily make it fit with the style of the others eg we'll prob best keep ILI9341_DRIVER for now

[ripe quartz]

Hello again I get off work in about 2 hours

Do you think we should write a driver for our specific device using what we can in parallel to other code

Like the unphone library

[steel robin]

Well with the unphone we had to as there wasn't one of our flavour in already, here we have to choose.

I honestly think that if we do it seperately it will be so similar that we may as well try to reuse what's there already

[ripe quartz]

gotcha

alrighty just pushed my changes so far

basically stole what i could and put it in CYD24 section

[steel robin]

ok taking a look..

[ripe quartz]

take a sec and in this section ```cpp

lgfx::Panel_ILI9341 _panel_instance;
lgfx::Bus_SPI _bus_instance;
lgfx::Light_PWM _light_instance;
lgfx::Touch_CST816S _touch_instance;

[steel robin]

Yup we're working towards all four of those

[ripe quartz]

change the Touch_CST816S to CST820

which is the actual IC on the board

[steel robin]

but hold off on touch for the min - I think only 816S is supported officially

they'rs supposed to be very similar...

[ripe quartz]

k

[steel robin]

and if we can't get the lgfx backlight working we can bypass it

[ripe quartz]

alrighty

I would like to take a moment and say I took all of this knowing it wouldnt work at the moment and have been focusing on getting the display just to light up

and possibly show a black screen

[steel robin]

yup exactly right!

that's what passes for sucess at this stage!

[ripe quartz]

most of what i do in the middle of the night is experiment to learn the codebase

[steel robin]

ok so just saw that main and screen.cpp's don't have your cyd24 in their screen setup bits

[ripe quartz]

yes

[steel robin]

so currently your work in TFTDisplay isn't run

[ripe quartz]

yes

that was next step I had deleted the changes i made to start fresh with you today

[steel robin]

ok so maybe we should do a quick sanity check, just try to get the backlight on with a blink sketch?

[ripe quartz]

sure

unsure how that would work but sure

[steel robin]

ok, just waiting for your latest changes to compile - which they seem to do!

right so lets get a simple blink sketch going and just check pin 27 really is the backlight

and if it is lighting on HIGH or LOW (presume HIGH)

so maybe easiest to just bang in into the top of the setup()

in main.cpp after line 210 add this:

    digitalWrite(27,HIGH);
    delay(500);
    digitalWrite(27,LOW);
    delay(500);```

[ripe quartz]

i threw it into a while(true) loop

[steel robin]

fair enough

better than worry we've missed the single blink!!

[ripe quartz]

i could do a for loop with 25 iterations or something just to not violate the never have an infinite loop rule

[steel robin]

this is strictly for testing a quick hunch - it doesn't have to be pretty or follow the rules so long as it compiles!

and because it would be good for our motivation to see a little action from the board

[ripe quartz]

flashing and compiling now

27 is indeed the back light pin

[steel robin]

Whoop!

[ripe quartz]

whooooooooooooop

[steel robin]

ok so did we decide to try to re-use the existing ILI9341_DRIVER section or get the parallel cyd24 one going first?

you decided rather

[ripe quartz]

i prefer to use the cyd24 parallel

even if one pin is different it may be worth it

[steel robin]

ok so shall I do some quick surgery and push changes or you?

[ripe quartz]

go ahead

just so your aware when working on a section of code please seperate it with 5 empty lines ontop and bottom

so it is easily locatable when scrolling at 100 mph

i used to do comment line breaks but they are a pain to clean up

[steel robin]

er ok, will go back and do that if important, but I've just made a dozen tiny changes expanding existing #if (defined(USE_EINK) || defined(ILI9341_DRIVER) || defined(ST7735_CS) || defined(ST7789_CS) || defined(HX8357_CS)) && \ !defined(DISPLAY_FORCE_SMALL_FONTS) to #if (defined(USE_EINK) || defined(ILI9341_DRIVER) || defined(ST7735_CS) || defined(ST7789_CS) || defined(HX8357_CS)) || defined(CYD24) && \ !defined(DISPLAY_FORCE_SMALL_FONTS)

compiling now

ok I think it's gonna compile, pushing now

pls pull, compile, flash and lets see if the screen lights up, or at least we see something on the serial monitor

[ripe quartz]

did you push to master or cyd24

[steel robin]

only cyd24, i thought you might have protected master or generally prefer to keep it synced to upstream...

[ripe quartz]

unsure if it pulled not seeing staged changes but will flash while I smoke real wuick

[steel robin]

you can look at line 18 of graphics/images.h and see if the CYD24 is mentioned to check if the most recent changes got pulled to your local copy of the repo

[ripe quartz]

weird no changes

ill write them in

[steel robin]

no it was my fault, pushed now!

[ripe quartz]

gotcha

got them

flashing now

should be about 240seconds

while we wait conceptually would it be possible to support UART Lora communication with an extensive amount of work?

i can see a #define UART_PROTOCOL

and a #define SPI_PROTOCOL

being used to make it possible

[steel robin]

I don't know for sure, but seemingly clever people say that the amount of data that needs to go back and forth to the radio is too much for UART, it's quite a bit slower than SPI

[ripe quartz]

ah ok that makes sense

[steel robin]

any that whole side of things is handled by another external library RadioLib, so it would mean going over there and making a PR into that code, with different people involved and for them meshtastic is just one small project using their library

[ripe quartz]

nifty

then figuring out a way to connect this board via spi to a lora module is going to be a pain

but worth it

critical fault #3 appeared on screen

on the cyd screen

whooop

[steel robin]

what?!?!

whehey!

So straight out of the bat, that's three of the four difficult bits done

can you connect a phone to the device? or has it crashed looking at serial monitor?

[ripe quartz]

Crashed

[steel robin]

well, not super surpising given missing lora stuff

[ripe quartz]

right

would it be possible to bypass the need for a radio and set it to standby

like a variant.cpp cyd_standby()

so its in a sort of false functional mode

[steel robin]

sorta, if you can share the serial output for the 20 lines or so before it crashes

[ripe quartz]

fault 3 is literally no radio which is why i say we need to bypass it

[steel robin]

and maybe try commenting out the radio init line 772 LockingArduinoHal *RadioLibHAL = new LockingArduinoHal(SPI, spiSettings);

[ripe quartz]

new flash started

so researching during flashes it apears that spi is possible with 6 pins

are you aware of a smaller lora module using spi with 6 pin standard?

[steel robin]

hmm well spi needs 4 alone, plus a couple of extra control pins

[ripe quartz]

if bare minimum works its possible

i can just wire it up

the board has 3 4 pin connections but total usable ports is7 i think

[steel robin]

I might have read about other people complaining it wasn't so easy as just using the pins they provided,

[ripe quartz]

io22 io35 io21

io 22 crosses over between two ports

then there is a couple gnds a tx and rx and 3v3

[steel robin]

I think we might need 3 extra control lines apart from the SPI 4

and the HT-RA62 module seems like it might work and is very cheap!

[ripe quartz]

with its pinout what pins could be skipped?

flash failed after commenting out the radio init

[steel robin]

grrr - do you mean the flash process failed or that it crashed again after flashing?

[ripe quartz]

flash process failed

[steel robin]

ok so maybe worth trying again

I found this basic use of the HT-RA62 https://resource.heltec.cn/download/HT-RA62/HT-RA62_Reference_design.pdf

[ripe quartz]

i vaguely remember a tf card to spi converter

possible option

[steel robin]

yes indeed. Hows your soldering ability / tools available? Microscope / hot air / lump of metal and a blow torch?

[ripe quartz]

i used to be able to weld but never actually tried soldering

harbor freight 5 mins away

i have a heat gun

[steel robin]

ok - you mentioned professor - does your school have a hacklab where you might ask nicely for some help and use their tools maybe?

[ripe quartz]

yes at another campus like 30 mins away but yes

[steel robin]

ok cool that might be an option. Lets have another go at commenting out some radio stuff because getting lora connected will take a new delivery wait plus then some soldering!

did it flash?

[ripe quartz]

i commented it back out and am flashing now

had monitor going which made it fail i think

[steel robin]

oh yes if you have that open in another window - if you use the built in platformio one it knows to close it first

[ripe quartz]

soldering the wroom board is terrifying

its so shiny i dont wanna mess it up

also set screen rotation to 1 in the variant file

just to see which way it turns

still have critical fault

3

[steel robin]

at same place?

[ripe quartz]

i believe so it was first thing that came on screen

[steel robin]

yes but in serial monitor also?

[ripe quartz]

Doing TFT init
INFO | ??:??:?? 0 Power to TFT Backlight
INFO | ??:??:?? 1 Turning on screen
INFO | ??:??:?? 1 TouchScreen initialized 30 20
DEBUG | ??:??:?? 1 Module wants a UI Frame
INFO | ??:??:?? 1 Not using WIFI
ERROR | ??:??:?? 1 NOTE! Recording critical error 3 at src/main.cpp:940
INFO ���������������M5�init, USB power=1
heres where it actually threw the error

i have this section set aside in the main.cpp

#if defined(CYD24)







//TODO: add CYD24 section







#endif

in here for now i would like to set up a initialize a simple ui
and bypass the need for radio

even if its just the meshtastic logo saying radio not found

and a blink on touch function

[steel robin]

yup having a look now

[ripe quartz]

so we can get the touch working

[steel robin]

try commenting out line 924ish router->addInterface(rIf);

sorry not that one! the one above RECORD_CRITICALERROR(meshtastic_CriticalErrorCode_NO_RADIO);

[ripe quartz]

LOG_DEBUG("thing we know about")

added this above the comment

[steel robin]

oh and prob also need to comment out this whole section:

        LOG_WARN("Radio chip does not support 2.4GHz LoRa. Reverting to unset.\n");
        config.lora.region = meshtastic_Config_LoRaConfig_RegionCode_UNSET;
        nodeDB->saveToDisk(SEGMENT_CONFIG);
        if (!rIf->reconfigure()) {
            LOG_WARN("Reconfigure failed, rebooting\n");
            screen->startRebootScreen();
            rebootAtMsec = millis() + 5000;
        }
    }```

[ripe quartz]

lol got it

ill recompile and see what happens

or flash rather

we have UIIIIIIIII

[steel robin]

omg!

ok see if you can pair with it!

[ripe quartz]

hang on picture

incoming

[steel robin]

post it in #firmware!

with a message saying 'development work in progress' or whatever you like!!

[ripe quartz]

ok fixing sizing problem

[steel robin]

oh ok right sorry just noticed the time! I've got to calm down a bit, get ready to sleep, go to sleep, then wake up tomorrow early....

[ripe quartz]

it has height and width backwards

[steel robin]

Fantastic work, well done. Maybe swap around height width or play with rotation more?

speak tomorrow probably

[ripe quartz]

thank you ... and good night

Ok so Bluetooth is showing up can't connect yet

[ripe quartz]

Good day everyone how goes things

[ripe quartz]

Got the bluetooth connected before bed as well

very happy with progress so far

[steel robin]

Nice

I was looking at the options and I think you'll need an SD card extender thing to wire in the lora module

[ripe quartz]

nice... ill see if i can find one

to fit the size

[ripe quartz]

@steel robin do you know anyone who would be willing to design the breakout board for us?

just for the concept

direct connection prefered for the cable so its lower profile

[steel robin]

I don't know anyone, I can't really do it myself honestly at the moment

[ripe quartz]

i am not learned enough for designing boards yet

sadly

[steel robin]

Well this one is fairly simple as it's just connecting things together.

But it is a bit of a learning curve to do your first board

[ripe quartz]

recomended method for getting it made?

[steel robin]

I'd be tempted to try the online design tools, maybe jlcpcb does one that links with their systems so you can press the button and get boards in the post

[ripe quartz]

because i am unlearned and do not want to screw up i sent a request into pcbway

[ripe quartz]

oh snap

thought occured

is the sd card SPI and how do I find out

[steel robin]

Yes the SD card uses spi

I found the schematic earlier hang on

[ripe quartz]

also here is my current TODO LIST:
implement touch

single button able to "unlock " and "lock"

get breakoutboards made

find 12 key library for texting
implement ^^^

[steel robin]

https://www.aliexpress.com/i/1005005902429049.html is the one you've got right?

there is a zip file in the listing, inside that I found a schematic for your board

[ripe quartz]

yes with capacitative

[steel robin]

I've got a fun one to add - RGB LED

your board should have one

[ripe quartz]

it glows red right now

lol

so yes it has one

[steel robin]

So try this for led activity:

#define LED_INVERTED 1```

in variant.h

but thinking about it, the led activity is for lora so you might not see it flicker

at least the led should calm down!

[ripe quartz]

it is brighter but blinking

[steel robin]

cool!

[ripe quartz]

so lets write an Alert_RGB file

[steel robin]

ok - great idea - so great in fact it's already been done!

try this:

#define RGBLED_RED RGB_LED_R
#define RGBLED_GREEN RGB_LED_G
#define RGBLED_BLUE RGB_LED_B
#define RGBLED_CA```

and then try playing around with ambient lighting in radio config, also external notifications module but that will need lora module i think

[ripe quartz]

lol

then touch implementation and add an onscreen log

ill push current status

[steel robin]

got to go - for touch implementation we need similar structure as around line 206 in TFTDisplay.cpp

but I don't know how much if any touch is in meshtastic at the moment, its comming soon. You could ask that question in #mui channel would be good to know!

[ripe quartz]

Rubber Duck: If (button==clicked){

if(sleepmode.active){
sleepmode.deactivate}
else if(!sleepmode.active){
sleep.activate}

}

class sleepmode{
void activate(){
//turn off backlight
//disable cs pin?

}

void deactivate(){
//turnon backlight
///enable cs pin?
}

bool active(){
if (TFT_BL==off){
return true;
}
}

@steel robin what do you think? would something like this work

[ripe quartz]

sleep.cpp line 500 TODO

[ripe quartz]

good morrow

how goes everyones day

[steel robin]

Hiya sorry been super busy recently

Your psuedo code looks good, there is already some sleep support, for displays as well as for the whole device I think

Tiny point, sorry can't help going into teach mode, in first conditional you are testing a bool so maybe you could say if else rather than if else if not. Not sure if that's significant really just for some reason I think the former is better.

And no need to wiggle cs pin outside of library or low level function, once we encapsulate low level functionality like a backlight enable or spi transfer, we need to avoid that sort of stuff ourselves in userland, and stay high level

[ripe quartz]

mmk

you should check out the last push of the code and see if theres anything worth changing

[ripe quartz]

I got a canned response on the breakout boards today

their engineer is taking a look at the poroject

[steel robin]

Hi and you did well to even get a canned response!

[ripe quartz]

Nice

Hi. I wish I had pin out of the project to get back to coding

[steel robin]

Do you mean a pinout of the cyd?

[ripe quartz]

Of the breakout boards that don't exist yet

@steel robin do you think you could help me find a 12 key library with gui we can modify to fit our needs

im having trouble finding one

ive been able to find a digital keyboard library and an numberpad library but nothing combining to two

[steel robin]

Yes probably I'm home in maybe 2 or 3 hours, can look then. Can you list the requirements?

[ripe quartz]

able to output letters and numbers/ as well as punctuation. in the number pad form factor... like the good old days of flip phones

able to have a pop up and minimize function

we can write that though

[steel robin]

And this is for on screen keyboard?

[ripe quartz]

yes

im aware we still need to get touch working

"always think ahead"

[steel robin]

Bonus features t9 auto word completion?

[ripe quartz]

if we can find it sure if not im not worried about it yet

[steel robin]

Ok! Back to driving now, speak soon

[steel robin]

Hello and sorry been busy recently!

I've looked over the latest code in your repo, it all looks good for the touchscreen implementation!

I see in variant.h that you are considering the RYLR993 radio - is that an old comment because that doesn't seem to use SPI hence a real problem

Recently I asked firmware devs if the existing ILI9341_DRIVER section with it's different style should be kept or if we should make it more like the other parts of TFTDisplay as we are re-working code related. Caveman99 said that the different style is because this TFT was the first to be supported and after this one the style developed. He encouraged us to reguarize the syntax as we are here anyway. So I think we should do that, also modify the existing m5stack-core variant as well, and use it for our purposes.

It will mean that we only need very small changes to TFTDisplay to make cyd work, and then also the display will be available to other boards not necessarily the cyd, likewise with touch, if we add it to the general ILI9341 section then it's available for other boards.

[steel robin]

I'm thinking it would be really smart to try to use the same library as the new gui will use in meshtastic - there is a dev version in the works https://github.com/mverch67/device-ui-project

[steel robin]

Seems like they are using LVGL

[ionic hemlock]

If you want to use the device-ui library with a standard esp32 based CYD and run meshtastic at the same time I can tell you already that this won't work due to too limited RAM resources.

What you would need is this one, CYD based on esp32-s3, e.g.:
https://www.aliexpress.com/item/1005004788147691.html

[ripe quartz]

Morning

@ionic hemlock AliExpress link is broken

[ripe quartz]

Yes it is an old comment a place holder until break out is finished

I see

[ionic hemlock]

Maybe it's not available in your country. It looks like this one:

[steel robin]

Ah - I hadn't spotted the limited RAM on this one, thanks!

[ripe quartz]

I have no experience writing ui in cpp it should be possible to write a ui lite for lower tier models if we want to tack that on to our list

[ionic hemlock]

You don't need to write ui code, that is already supported by the device-ui library once it is merged into firmware code. The thing is that with the esp32 CYD you can only display the "OLED UI" (which nobody likes to see on a TFT touch device) or a very basic colored UI with very few widgets. Or you upgrade your project to esp32-s3 and get the ui automatically as implemented by the device-ui lib.

[ripe quartz]

Ah ok

If I can find one I'll order it

[ionic hemlock]

Before you order one make sure that its display driver is supported by lovyanGFX. I found a very similar device to the one above which has an ST3401A display driver which would require an own implementation (not using lovyanGFX).

[ripe quartz]

No 2.4 sadly

[ionic hemlock]

If it's 2.4 I would recomment resistive touch that can be used with a stylus. The virtual keyboard keys are really small.

[ripe quartz]

It's going to be a few days before I order

[ionic hemlock]

The T-HMI is already supported for serial connection:
#mui message

But this device has a parallel display interface, so not much pins left for a LoRa connection

[ripe quartz]

@small hamlet this project needs some board design

[small hamlet]

I will read through the thread and whip up some designs

Do I need to be aware of any particular thing ?

Give me say 14 or so hours I can get something done tonight

[ripe quartz]

needs 2 break out boards one sd/tf male to ribbon cable. and one ribbon cable to the pin out of this module

to be able to directly solder a ribbon cable to both breakouts for no extending board beyond the cyd. and to mount the lora module on the back of the board and slightly to the side via ribbon cable bends

[small hamlet]

Ohhh ribbon cables hmmm

This one's a tough one

I haven't worked on double sided boards let alone with ribbon cables

[steel robin]

Hello and glad to see another person joining

I found this cable on AliE - https://www.aliexpress.com/i/1005005121612747.html

We could use their cable, cut off or desolder the socket, and directly solder the cable to the new single breakout board that would hold the lora module

so we'd only need to design one board, and it would be easier job too!

[ripe quartz]

Nice find

[ripe quartz]

I have no skills for this so you are ahead of me

Quick rundown of where the project's at. We still need to get touch working and connect a Lora module with the above mentioned breakout board

Display output is functional

And we are at a standstill

Once this sprint is complete we add a touch 12 key UI similar to a original text messaging keypad

Aka aNumber pad with letters

[steel robin]

I'll have a look at touch next, perhaps you could start to look at using lgvl library for 12 key UI? It looks like it can do it and will be the new solution for meshtashtic v3

[ripe quartz]

for sure

[ripe quartz]

I looked thru lvgl and found a raw number pad but no 12 key

Just snagged qt and going to see if I can learn it to make a simple 12 key UI

[small hamlet]

Aight lemme give it a shot

[small hamlet]

Ye gotcha

@ripe quartz

If possible can you hope on a call in about 6 or 7 hours from now?

Hop*

[ripe quartz]

yes

Dont hold me to this but I think its possible in 2 layers

[small hamlet]

I will have to learn it but if worst comes to worst we can just use extenders and make a "sandwiched" board

Lot of new things come into play crows capacitance and interference from other smds

[ripe quartz]

seeing what i can do in Qt

[small hamlet]

Looks neat !