Welcome back to Cnutelectronics! It comprises the same bone headed ignorance, overenthusiasm, poor research, pointy metal things as Cnuteneering and also adds the additional danger of very hot soldering irons.
We left the last episode of Cnutelectronics with a working TFT screen. Now, for the UI I have in mind, I need to be able to switch between swords and test each socket line individually, as the swords are wired and report button presses differently.
I happen upon this suite of UI design and more importantly, coding tools. It comes with a desktop application where you can design your screens, and then goes off and writes all the horrible code that sits behind it all, tedious reams of “this font, this size, this colour, do this if clicked”.
The UI is pretty easy to use, and it supports the idea of a “base” screen which sits nicely with what I have in mind. I am thinking of 3 screens, one for each blade type – epee, foil and sabre. Each screen should have 3 buttons to select which blade is to be tested, then a set of blade specific tests can be run.
So this is the base screen – these buttons and battery charge indicator should be on each screen.
I can now define each screen in turn – this is the Epee screen. It overlays the base screen, which is neat as there’s no duplication of the code to create and manage the buttons on the right hand side.
I mentioned battery indicator just then but up until now, the power has been coming from the computer that the ESP32 is plugged in to, so I can program it. In usage, I want to be able to bung the Blade-O-Matic into my fencing kit bag and take it with me, and that means battery powering it.
If only I had some means of charging batteries! Oh wait, I already do – the Solar Powered Temperature sensor was battery powered, all I need to do is cut out the solar part, recharge the battery from a USB port and I am good to go. I solder up another battery charging circuit. For once I am glad I had to buy 5 charging magic chips and LDOs (voltage drop chip) instead of the 1 I wanted.
There was a little faffing about in the generated files from GUISlice so I can tell it what pins on the ESP32 were connected to which ones on the TFT, to drive the screen and so on, but what I soon realised is that while GUISlice supports many touchscreen chipsets, it does not support the GT911 which is what I have.
Once again my lack of research comes back to bite me on the arse.
Now, the TFT screen uses SPI “language” and connections to connect to the ESP32; the GT911 uses the familiar to me (or so I thought!) I2C connections and protocol, and it has its own connections on the screen pinout.
Smart puffins will remember this is just a SDA/SCL pin combination – Serial DAta in a stream of 1s and 0s kept in time with the Serial Clock signal. After quite some failure to get things working – even with just a noddy test harness program to read the screen keypresses, I was getting nowhere.
Verax Cincinnattus I think, pointed out that SDA/SCL lines usually need a so-called “Pull Up” resistor. Nothing to do with Pull Up pants for the elderly, the very young, or presidents of the United States, these guide the signal so that transmissions have to overcome the existing voltage, and this apparently gives sharper transition lines in the voltage graph, so it means that the chips have a better chance of talking to each other and understanding the transaction. Nice crisp square waveforms and all that.
Oddly, this was never a problem on the BM280 chip I used in the temperature sensor, but I duly added some pull up POWAH to the unit. In contact with the seller of the screen, they also advised that the RST pin should also be pulled up, to prevent the screen from randomly rebooting itself. Somewhat humbling again as something I thought I understood reasonably well turns out to be yet another deep sea of my ignorance in which to swim.
In any case I did a hell of a lot of reading, exacerbated by the fact there was no _single_ manual on this particular device.
Searching for this model number revealed a couple of places to buy it, but nothing more. Google has ceased to be my search engine of choice, the transition from internet as a useful resource to large shopping centre seems to have completed. I reckon in 3 years Google will no longer be the primo search engine unless they have a radical think on how they do things.
No matter, I find the GT911 (touchscreen) manual and an ILI9488 manual just for the sake of completeness. I went through every bit of public code I could find that drives the gt911, from embedded RC plane control systems to backroom hobbyist coders, and nothing I tried seemed to work.
The hard part of working with hardware at my level of incompetence is that if stuff does not work, it could be the hardware, the software or the physical connections. It turns out that the GT911 can either be polled on the I2C channels, or it can push the INT pin low when it the screen is touched. When this didn’t work I contacted the vendor again who informed me in curt Chinglish “no use interrupt pin” which I was less than happy about. At least now I know I have to go with the polling method only.
Once again, the euphoria of shiny new components and a cunning plan in my head gives way to the slow grind of reading, re-reading and reading manuals again. By now I could probably recite the GT911 developers manual backwards, the memory mapped IO registers showing the state of the chip and screen touches, the special modes it has and so on.
As it happens, the chip is too clever for my own good – an I2C chip will have an ID so that multiple I2Cs can live on the same bus. When you send an I2C message to the I2C bus, you also send the ID number of the chip it is for, so that that is the only chip that listens to the message following the ID.
The GT911 does not have a hardcoded address, it can be one of two and you need to tell it which to use. This is done by holding a couple of pins HIGH or LOW (INT and RST pins) for a specific amount of time as per diagram:
Coding for an ESP32 is a pretty weird concept – there are C / C++ libraries grafted into the Arduino coding studio (Integrated Development Environment) that are compiled, like the Bodmin TFT SPI library, but for some reason cannot be readily displayed in the Arduino IDE and line by line debugging is not possible.
The Arduino IDE is already hacked (in the sense of the original term – make something do something it was not designed to do) so it can “talk” ESP32 instead of Arduino chip specific Arduino-ese. It is back to old skool “print the variables to serial line” style development and hope you’ve captured everything. I must work out how to actually do line by line debugging but for now, just getting some checkpoint info back “reached this line of code” is enough. Plus it takes me back to my 8 bit days for some lovely coding nostalgia.
The deal is that the libraries I use are added into the Arduino IDE project, compiled and then transmitted to the ESP32. What this means in reality is that I end up having MS Visual Studio open so I can see the library code, Arduino IDE so that I can see the “headline” code running, and then also my constant companion at the minute, the GT911 manual.
Busy times indeed on my screens!
By now I have most of the electronics components sorted and it’s all ready to be connected together:
And here it is, running on pure battery power only, with the touch screen actually working! Either the faff with the I2C ID, the rewire, or some god of *eneering was smiling on me that day.
Now, all of the hardware and software is talking nicely together – I have the basics to run the actual tests on swords I want to run. The problem is – I also want to be able to test the body wire in isolation from the blade itself, and that means more circuitry.
Here the idea is the Out socket is connected back to the Epee In or Foil In socket through the body wire. This will allow me to test wires A, B and C are not damaged. This happens quite a lot – body wires get hit, stretched and bashed about seven different ways ‘til Sunday.
This is my first mockup of the circuit:
The idea being that the switch in position 1 kills the power to the ESP32 and we have a basic continuity test. In position 2 the ESP32 is powered and I can intelligently probe the connections between A, B and C depending on sword type.
I then realise that the A, B and C will all register shorts when the ESP32 is active, even without a sword plugged in.
What would make things really easy here would be a 3 position switch that has an “everything off” setting in the middle, push forward for ESP32 and backward for continuity test. That would need 3 separate lines to connect wires to, and nowhere seems to sell them. Double connections, yes, triple connections, no. After I had bought the kit, leopard pointe out that there are rotary switches that have 3 and more poles to connect to. But ah well, I have the switch now…
So I knock up a circuit with transistors to use the physical switch to run as a trigger to put the transistors ON or OFF and make or break the circuit that way.
Our very own leopard was very generous with his time and expertise and made some corrections to my circuit, adding in some protective resistors
I then realise I can probably just do the same with ordinary diodes
Which my newfound guru leopard kindly made better for me:
So now I have the circuit ready to go. I do need to try to work out if I can get the ESP32 to measure the voltage and hence calculate the resistance of the sword when the tip switch is closed, as the scoring boxes measure this for hits.
Our leopard also recommended I knock up the circuit to test it and although that sounds close to research I will class it as development and give it a go. What I don’t have is a reliable 3.3v supply, so off to Amazon for some kit:
The bit on the left is the USB transformer and it outputs both 5v and 3.3v from a USB connection. Not bad for less than a fiver! Plus some more soldering iron tips….
This is the first cut of the circuit – just 2 leds but that should be enough to measure any backward leakage of voltage when the ESP32 mode is engaged.
In the above, the yellow cables are the body wire connections, the green wires will go back to the ESP32.
I now remove the “body wire” connections and I test to see if any positive voltage is leaking through the diode. I have an old Arduino “bag of components” that I use a 1N4007 diode from, as well as a newly bought 1N4001 diode in the circuit.
The first measurement is quite encouraging – the leakage is 10.3 milliVolts which I am not entirely sure that the ESP32 will even register. So far, so good!
But, there seems to be some kind of capacitance going on as every second or two, the voltage measured jumps to 1.329 Volts which is not going to make any reliable measurements possible.
However, on the shiny new 1N4001 diodes, the output is pretty steady around 0.272 Volts. I can probably live with that.
So now I just need to solder it together. The many-armed soldering station proves its worth – get everything lined up ready to solder and then go for it in one fell swoop. Note the use of protective mini crocodile clips to act as a heatsink and protect the components from the heat of the soldering iron.
And that is it! The coloured leads on the left will go back as signal cables to the ESP32, the red wire will go to the switch.
Now I just need to get all of these parts into the box at the top left of the picture. The box is a bit bigger than I would like but it was the only one I could find that was deep enough to hold the ESP32, battery and screen in one plane.
All that is left now is the fitting to the box, and I just need to write the tests to check each sword type, then test it all. But for now, there are more pressing matters to attend to:
© El Cnutador 2023, named pics © leopard plus all the bits that took a bit of skill.
