RE: How to code several cap-touch buttons as several "random/asynchronous" GPIO input interrupt button or switch press (no scanning to detect) - MCU = MKL28Z512VLL7
I need help about “converting” self-cap touch to GPIO interrupt input trigger just like any other button or switch press/release action, rather than scanning method which will not be feasible to my product development.
I have at least 3 cap-touch buttons to BEHAVE AS GPIO together with other regular electromechanical buttons & switches & probes contact – BY HARDWARE INTERRUPT INPUT TRIGGER. I have 80+ pin I have setup/routed using the MCUXpresso pin tool, 3 out of 81 I/Os are capacitive touch buttons.
I cannot & should not scan or poll as the trigger will be missed because MCU will be under FreeRTOS multitasking & doing MANY OTHER THINGS other than waiting for touch buttons.
I’m using MCUXpresso & I don’t have IAR or other IDE & I do NOTwant to install anything anymore as “temporary” IDE, etc.
But AN4637 using Touch Sensing Software in GPIO method specifies TSS library that cannot be installed in MCUXpresso.
I opened some tickets on this but technical support has been Unsupportive except for the most recent one who gave me link to the folder on NXP that has some (but not all) of the FRDM-KL25 demo source code files, *.c & *.h.
I've started tracing & analyzing this code logic in order to apply GPIO interrupt input method trigger (ala-button press) on the MKL28Z using its FRDM-KL28Z eval-bd.
There are plenty of source files on the directory you pointed me to but for some reason, I can't find all the definition for the functions that's paired with the prototype header file "TSS_API.h".
I don't see "TSS_API.c" C-source file which is where I think a big chunk of the setup, configuration, initialization functions of the touch pins to behave as GPIO are.
For example, the missing functions I would like to view the source code which are missing from any of the source files are:
TSS_Init() - how to code setup, configuration of a touch-capable pin to behave like GPIO input?
TSS_SetSystemConfig() - other necessary configuration code?
TSS_Task() - how does it catches the touch event like a button press???
... just to name a few.
Where & which source code file can I find them?
If you don't know where the code is, does anyone who actually have solid experience in programming such setup explain how they did it?
Based on my trial & errors using SDK imported code project of "touch" sensing, they have to specify an "electrode" first & then do a "timer interrupt" handler (link electrode scan to timer tick, if I understand that correctly), then in the handler function, verify if the touch was that electrode that is waited on. But with MKL28 it seems that you can only specify ONE & ONLY 1 electrode at a time! which means TSI module only scans for ONE electrode at a time? Because this is a 16-bit register BIT-MAPPING, & parsed by MASKING each bit. So no 2 or more bits can be set AT A TIME or else the value of channel count is >15 which is invalid channel # (valid is only 0-15, for 16 channels for this MCU).
Long story short, I've exhausted many ways I can think of how to make touch channel behave like RANDOM GPIO interrupt input event so please help me so this MCU can handle at least 3 cap-touch trigger at any random time not by scanning electrode 1-then 2- then 3 in sequence - THIS WILL CAUSE a touch event to be missed because as I said I have 81 GPIO operations that needs to be taken cared of.
Thanks for the help.
That's why my subject line requests for method to relate TSI module capability to behave as separate GPIO interrupt input pin just as how MCU KL25 application note AN4637 document claims it can.
My problem is its SDK only loads in IAR and not in MCUXpresso, just so I can browse through the setup logic to see how I can apply the same idea to my MCU KL28Z. Aldo send me a link to some source file BUT the actual pin initialization / setup .c/.h files ARE MISSING. NXP claims it's with the IAR library. I can't install IAR because of our IT dept's "block" to install trial version. I think it's the humongous 1.3GB size of this ARM IDE application.
Not able to view KL25Z's pinout configure does not stop me even if I can't see THAT INITIALIZATION CODE. So I'm experimenting different ways by myself for the KL28Z.
Also, another kinetis, MCU KE15 has TSI module technology v5.0 compared to KL28 which has TSI v4.0. I was told by NXP support that TSI v4.0 is "more powerful" than TSI v5.0 but why is the version number lower? Also KE15 has 24 touch channels while KL28 only has 16 touch channels.
QUESTION: Does anyone know what KL25Z (touch works as GPIO) TSI module's version is?
Also whether I import KE15Z SDK or KL28Z SDK regarding simple touch driver example, the source code LOOKS THE SAME, including the initialization - like the TSI module's technology version is "transparent" to how the FW uses.
One thing good on the KE15Z example though is there's specific function that is called for the "SW trigger" which gave me idea how the scanning through all 24 touch channels, how touch is detected, etc. is done.
If anyone has IAR access to KL25Z touch to GPIO config source files listed here, would you please send or attach them here. I need them to see if that "idea" or method that converts TSI to GPIO, understand it, and see if can be applied to KL28Z.
These are the files missing from the zipped folder I got which are THE INTEGRAL source files that would have initialization/setup code, function calls, pin configuration on the working KL25Z:
TSS_API.h (functions: TSS_SetASliderConfig(),TSS_GetASliderConfig(), ....etc.)
Thanks for the help.
The application note in question refers to a method of creating a "TSI like" function using GPIO and a HW timer. It is a "poor-man's" method of emulating TSI when the TSI peripheral is not available (eg. in very low end KE or KL parts). It has HIGH SW overhead and LOWER performance than the TSI peripheral (like bit banging a UART when you don't have a real one available).
The technique will certainly not be of any interest to you if you are already worried that real TSI will not be adequate: It will not make things faster or more more powerful but will consume unnecessary CPU power in a system where you are already worried about performance.
Since GPIOs already have the edge interrupts that you need turning a GPIO into a slow TSI has no advantage. The application note DOES NOT turn a TSI only pin into a fast GPIO....
I'd like to ask, have you actually looked at those source files I'm looking for? I'd like to know where you got your "conclusion" / statement from.
I beg to disagree with your statement, because the MCU KL25Z used in the example has TSI (Touch Sensor Interface) with 16 touch sensing capable channels (just like my target MCU KL28Z).
And so that's why the AN4637.pdf's has the title:
"Integrating Touch Sensing Software (TSS 3.0.1) on Kinetis L Using GPIO Method" using that MCU KL25Z touch capable pins and instead of regular "scanning" the pin with TSS method, they convert such touch capable pin to generic GPIO input pin.
Please provide basis for your statement that it is the OTHER WAY AROUND - the touch capable (TSIO_ch#) pin is just used as probable "default" generic GPIO input - WHICH IS ACTUALLY THE METHOD I WOULD LIKE TO LEARN.
You see not all GPIO pin is Touch capable in any MCU; only 16 out of 80 in both MKL25Z and MKL28Z for a fact, as TSI0_ch0 through _ch15).
So someone writing a whole application note is a waste of "TSS" technology when it is already built-in in the MCU.
Now the trick is to fall back and make that touch capable TSI0 module or not even use that built-in technology and make any GPIO trigger by touch. How? As a generic ANALOG input? I can do that and I also have 6 analog inputs that go to the internal ADC. But I would like the actual source code to see an example to get an idea how they do it.
The sources are confidential to Freescale/NXP and they will neither give them to you nor to me .
The application note's introduction (plus various additional details in the general text) makes things quite clear to me:
You could try reverse engineering the library using IAR if you still have doubts. If your IT department won't let you do it in the company just do it on a home PC - this is the typical engineering method used when IT department red-tape gets in the way of progress.
Your KL28's TSI inputs can be configured as either TSI inputs (using the DMA method as recommended by NXP and myself you will get zero overhead operation with a resolution of well over 1kHz which is adequate for an HMI interface) or as HW interrupt (if you prefer to replace touch keys by mechanical ones).
As always, I also did not stop there especially since the example PARTIAL code shown on further pages specifically used 2 touch-capable pins.
No, I do not intend to use mechanical buttons because I already have 5 of those SEPARATE from the 3 capacitive touch buttons. I've tried the KL28Z SDK to do hardware interrupt on the capacity touch channel - it actually TRIGGERS without scanning like a regular interrupt falling-edge mechanical button.. PROBLEM: that's only 1 and only 1 channel at a time. If I need 2-3 or more than 1, that's what this post is here for ... it cannot be done except by always "sequentially" switch from channel/electrode 1 pin (wait for trigger), then channel/electrode 2 (wait for trigger), then channel 3 (wait for trigger)...
No can do. I need RANDOM, non-sequential channel/electrode monitoring NOT scanning one at a time, just as random as my 5 mechanical buttons are, BY INTERRUPT GPIO INPUT trigger event (falling edge) boom!
I believe KL25Z has done it but why the fuss about keeping it "secret"?
Like I said, I will try other means now...
I trust that you will report back when you have solved it since I don't yet know of a more efficient method than using TSI and DMA and so would be interested in learning of a better solution.
Note that there in no need to waiting for a triggers in DMA mode - sequential scanning is just sequentially "sampling" without any waits. It thus detects any inputs in any random order (and only interrupts the processor when something has been detected by the HW, thus needing no CPU overhead). The only drawback of sequential scanning is that the sampling period for each input increases for each input in the sequence. Eg for a single input with 50us sampling rate it increases to 150us sampling rate for 3 inputs but this would only be an issue when press/releases faster than 6kHz were needed.
I have found a way, actually 2 ways. No, nothing to do with DMA and such complications. But it is not fully single-independent 100% GPIO-method because of the LIMITATION in NXP's Touch sensing interface technology for channel mapping as I've learned about the 3 MCU's I've looked at: KL25Z, KE15Z, KL28Z. All channel, whether 16-channel or 25-channels are MULTIPLEXED. Even though you see separate GPIO pins on the outside are assigned a TSI0 channel function, INTERNALLY, they are NOT physically, one-pin-to-one-channel correspondence. So for TSI0 16-channels, there is no 32-bit port assignment of 16 bits in that port. Instead, there is only 4-bits assigned for 16-touch channels.
With that information, you realize there is NO WAY SEVERAL (>1) external capacitive touch pins can independently be detected TOGETHER any time, at the same time, because for more than 1 touch channel, you need to "reload" the TSI0 module with A CHANNEL to scan/check - need to set which channel in 4-bit map in register should be scanned - for 4-bit load ch0 = 0000, ch1 = 0001, ch2=0002,..... ch15 = 1111.
So direct 100% GPIO input PER PIN interrupt trigger is IMPOSSIBLE to do among these MCU's. Needs to be compensated in firmware by first loading the port register with correct channel (in 4-bit format) and then WAIT FOR TRIGGER (counter+delta value) to be detected on that channel. It can still be hardware (charge sensing) interrupt trigger but you still need to "rotate" or "change" channel number in register, each time.
If you get the drift, I don't have to explain in detail to you how I did it. Basically, there is need for FW intervention to switch channel each time because there is NO DIRECT pin-to-channel one-on-one correspondence to interface to TSI module. Literally, TSI module cannot scan several channels in one row because it only knows 1 channel in its 4-bit assignment register, one channel at a time.
My question to you and others now is, is there an NXP MCU that actually has one-to-one, HW pin-to-TSI-channel direct connection externally and also internally that there is no need to constantly rotate/change the channel in the PORT register - basically an MCU with full 100% GPIO (analog) hardware interrupt input trigger direct to touch sensor module that does not need FW intervention to switch channels?
You know, just like 1 ADC/DAC input trigger, or 1 mechanical button interrupt input press/release trigger, an MCU that can scan several channels in one row of full 16-channel scan. Is there such an NXP MCU?
I'm sorry for long explanation. I apologize if I confused anyone with that above slightly convoluted diatribe.
Thanks for your idea.
Like I stated on the subject line and as I've told some of NXP tech support who suggested similar method to me before, I would like to avoid synchronous or sequential scanning, which is what your idea is proposing.
I would like a direct button-like HW interrupt input trigger that can happen at ANY time, randomly.
A sequential scanning, e.g. "... then circle back to the first one..." you stated could cause a "touch" TO BE MISSED.
Say the MCU or TSI module is scanning channel 3, but then at that moment touch channel 1 was pressed, then THAT TOUCH IS MISSED.
Or if module is scanning channel 2, but same moment, touch channel 3 was pressed, then THAT again is missed.
I need to configure a touch-capable pin to BEHAVE LIKE A GPIO that has an electromechanical momentary press/release button attached to it which I can setup to do HW interrupt trigger on say, FALLING EDGE or RISING EDGE.
The TSI in the KL28 scans only one channel at a time so the only solution is to sequentially scan each at a fairly fast rate - if you are detecting key presses activated by humans this will be no problem since you can scan keys quite quickly (eg. 50us per input and so a scan or 3 inputs each 150us (or at an effective sample rate of 6.6kHz per key)) which means that you will never miss a key press that is less that 150us in duration.
If you effectively need pulse detection that is very short (for example less that 50us pulses) or ultimately edge detection you will also not be able to do it for a single input. In this case you need to choose a solution that has the appropriate HW capability rather than a touch sensor.
Complete KL28 solutions, training and support:http://www.utasker.com/kinetis.html
Like I stated before, I have 81+ and counting... I/O to take care. Sequential scanning of 3 touch channels out of 81+ I/O's is "NOT" easy TASK. I know I'm assigning a task and driver handler for "touch" business & there will be multitasking timeslot sharing by e.g. FreeRTOS but I'm worried because of the MANY OTHER task that I need to take care of.
Worst comes to works, I will need "touch" to be higher priority than the others or maybe equal to other also important tasks like other regular button presses and pumps on/off mechanisms.
It's going to be part of my architecture design documentation what is best to do for my product.
If you have or can view the files I'm asking for on my separate post the other day that lists source files I would like to view and study, please provide.
Thanks for your help.
I have not stopped at the KL25Z example. I tried installing IAR evaluation but unfortunately our IT admin has "blocked" this 1.3GB installation and they haven't gotten back to me for solution as their expected solution does not work.
I have kept on experimenting using FRDM-KL28Z as how it can be possible within its capabilities.
I have been balancing the possibilities, combining, eliminating, removing timers, enabling/disabling TSI module, setting GPIO as analog or regular GPIO digital input, enabling INTMUX0 using 2 of its 4 channels, using same port, e.g. B for all 2-3 touch buttons, etc., etc.
I have a plan that is on hold because I need to do some architecture documentation right now BUT I believe that eventually I will be figuring out what will make multiple touch buttons work as asynchronous, random INTERRUPT EVENT (just like another momentary press/release button or contact/no contact probe trigger) WITHOUT needing to do periodic scanning of each touch button sequentially.
Right now I have continued to do "experiments" on the side because after I complete my FW architecture & design document, I have to face these fact - I need 3 cap-touch buttons to work INDEPENDENTLY and as random input interrupt event just like an ordinary switch or button.
If anyone here has an idea, please do share.
Thank you for the help.
Assuming you have a free DMA channel and have connected TSI pins (and not general purpose ones) to the sensors:
1. Configure for the first input scan with DMA request on the end of scan flag and trigger it to start
2. Use the end of scan DMA request to trigger a transfer of the next channel setup (the threshold values, the mode and SW trigger to kick it off (alternatively use LPTMR0 to HW trigger it at a slower rate)
3. The DMA mode is set to work through each of the TSI inputs and then circle back to the first one, which means that all required TSI inputs will be continuously scanned with no SW intervention.
4. With the thresholds set so that a key press generates an out-of-range interrupt any pressed key can be detected via interrupt (note the EOSDMEO mode select needs to be set to enable end-of-scan DMA and out-of-range interrupt at the same time).
5. Subsequent key release can be detected by the same technique if the out-of-range threshold is shifted accordingly until it fires again.
Complete KL28 solutions, training and support:http://www.utasker.com/kinetis.html
Unfortunately, as I already mentioned you, the TSS library is only available for CW and IAR.
We do have some of the files as .c and .h but there are some files , the files you are referring to, which are precompiled libraries that we do not share in any other way than that.
Sorry for the inconveniences this might cause you.