DECIDED AGAINST ARDUINO TEST
I am reaching the point where my interest in continuing to battle the XPT2046 touch controller chip is disappearing. There is a solid alternative making use of physical buttons for the up, down and selection toggle functions, thus eliminating the need for the stylus and touch operation of the user interface.
Frankly, the stylus would be easy to lose inside the 1130, particularly as they will be operated by multiple people in a museum setting. The screen is small and human fingers are therefore relatively large, but it might work out to simply tap with fingers.
The Arduino boards I have in stock operate on 5V signal levels, not the 3.3V used by the Terasic DE10-Nano and the LCD Module. I would have to wire up level shifters, which adds time to setting up for an Arduino based research effort.
I committed to investing only a few more hours today trying out different changes to communicate successfully between the DE10-Nano programs and the touch controller. I am a volunteer at Cape Canaveral Space Force Base guiding press, VIPs and workers who registered to watch a launch. I have an assigned location, in this case about 7000 feet from the pad where the Delta Heavy will launch in the early morning hours. Until I leave sometime after midnight to enter the base and drive up to the viewing spot I am supporting, I can bang away varying things to see if I can talk with the chip.
I Googled to see if others had experienced issues with the touch controller and did find a variety of complaints and some solutions. Most made use of existing libraries on platforms like Raspberry Pi Pico and Arduino rather than directly coded access like my code.
A few mentioned never getting the touch part of the LCD Module to work, speculating that crappy clone or pure counterfeit chips were on some of the inexpensive modules being sold on eBay - where of course I purchased my modules. I guess that is one possible explanation that would encompass two modules behaving exactly the same.
One mentioned having to change the SPI mode to communicate with the chip, different from the mode CLEARLY drawn on the data sheet. Another expressed challenges getting the high resolution 12 bit sampling to work but received 8 bit results more reliably. Since my last tests are more of a desperation mixed with a choice to invest a few hours tonight to wrap up the controller communications test, I focused on these possibilities in my remaining experiments.
TESTING WITH LOW RESOLUTION 8 BIT SAMPLING
First up was the easiest, simply changing the command to request a low resolution 8 bit value. I did this with both the temperature sample and the X axis position sample transactions.
My temperature measurement command was 0b10000100 which is composed of the start bit, a three bit selector of 000 for temp measurement, a 1 bit resolution selection of 0 for high res, a 1 bit measurement type bit of 1 indicating single ended electrical sampling, and the last two bits are the default behavior to power down and remain listening for touch interrupts after the data was returned.
That command is altered to 0b10001100 to request a single ended measure of temperature with low resolution instead of 12 bit resolution. If the issue was failure of 12 bit sampling, I should see values with this command instead of the return of 12 bits of 0 that I have been experiencing.
The X position command has a measurement selector value of 101, so that the command for differential measurement of X position at low resolution would have the command 0b11011000 instead of the 0b11010000 that I had been using for high resolution requests. That should spit out up to eight non-zero bits on MISO indicating that the chip responded correctly to this.
Whether low or high resolution, we got back nothing but zeroes. This is not the explanation.
VARYING THE SPI CLOCK POLARITY AND CLOCK PHASE SETTINGS
The LCD controller chip, on the same LCD Module as the touch controller, definitely works properly with clock polarity 0 (idle state low) and clock phase 0 (sample incoming data bits on the rising clock edge). This is called mode 0 by some people. It would be ironic if I not only have to change the speed of the SPI link to talk to the touch controller but also the SPI mode, but that is indeed possible. I call a function to disable the link, switch baud rate and re-enable, so why not change the mode as well?
I set up a sequence of tests, covering all the permutations of polarity and phase. Mode 1 has the same low clock polarity but switches clock phase to sample incoming data on the falling edge of the clock. This can have the result of missing the first bit of a byte if the mode set for receiving has a different mode than the sender, but in this case it won't matter!
That is because the wonderful XPT2046 chip is not really byte oriented, it is a bit stream device. Once it has completed any prior sampling of data it was performing, it just watches incoming bits until it sees a 1. That starts the sampling and then analog to digital conversion. After a 1 bit kicks of a transaction, the next 7 sequential bits contain the rest of the command, selecting which measurement to take, single-ended versus differential, low versus high resolution, and behavior once the sample data is returned.
Following the 8 bits that began with a 1 the chip needs one more bits (clock cycles) to finish sampling before it spits out the 8 or 12 bits of low or high resolution measurement. Thus we have 8 bits of command, 1 bit of padding, then 8 or 12 bits of data.
Immediately after the last data bit is received, you can send a 1 bit to start this up again - therefore not on an even byte boundary at all as we had 17 or 21 bits total from the last sample transaction. When dealing with microprocessors and protocols like SPI that are framed in units of a byte, we simply continue to send 0 bits after the last data bit was received until we count out the full 24 bits, 3 bytes of a transaction.
If we were driving the chip with discrete logic, an FPGA or something else that didn't require even byte boundaries, we could operate with the streams of 17 or 21 bits. Fortunately, this means the XPT2046 would be insensitive to errors where SPI mode mismatches put the start bit as bit 1 of a byte instead of bit 0.
The controller chip really doesn't care about bytes and simply reads incoming bits until it sees a 1, after which it interprets the next 7 as the command parameters, ignores the following clock cycle, and then returns 8 or 12 bits of data. If we are out of alignment, I will still receive the 8 or 12 bit value, just shifted by a bit. We already have to deal with the measurement sprawled across two bytes when receiving it on a byte oriented system or link, so there is shifting involved to turn it into a right justified 8 or 12 bit unsigned integer.
All four modes were tested with identical results. Nothing happens at all. Not even sure if this is a real chip or just some inert junk inserted by the penny ante chiselers of the low cost electronics manufacturing world, who will make counterfeits or use substandard shoddy substitutions to wrest another penny or two of profit. Often done in societies that theoretically are not profit driven.
ONE MORE TEST I MIGHT DO TO SEE IF THE CHIP IS EVEN PRETENDING TO WORK
The data sheet shows that a pin called Busy should go high in the midst of a sample transaction for a short interval. That pin is not connected on the LCD Module but I was able to put a mini grabber on the lead and hook it up to the oscilloscope. Triggering the scope on rising edge, I will be able to tell if the chip is going through the motions at all or just a silicon brick.
However, the form factor of the controller chip is small enough that my grabbers wont fit on a pin without shorting to adjacent ones. I would need to tack solder a wire to the pin, something that would require me to drive over to the workshop to accomplish under the stereo microscope. It just isn't worth it. I am proceeding rapidly to yank all the touch panel stuff out of the project and build it around physical interface buttons.
No comments:
Post a Comment