ptc suppot

[MX682X]

my biggest pet peeve so far is the missing ptc support....
So I've looked through the assembly, together with ghidra and wrote a basic library to support selfcap and mutual cap buttons.
It is based on the qTouch Modular library, but I tried to do it differently, as much as reasonable, to avoid getting smited by MC (better safe then sorry). Furthermore I'm not gonna do the other stuff like sliders and 2D surfaces.
I've also realized that qTouch does a lot of pointer arithmethic due to the structure of the struct types. By avoiding that I was able to shrink the library size aswell (about 50% I guess).
Also posting it here for now because:
A. It has research about the PTC registers
B. Trying to keep it off the radar for now.
C. Maybe get some feedback for the user interface
sketch_apr04a-002.zip

P.S.: Fun fact: The DA has actually two ADCs - the second is inside the PTC module - that's why the Tiny PTC "Takes over ADC0" but this restriction does not appy to DA. Not so fun Fact: As the register layout is different, the DA will need it's own library... (the 328PB is V1, the Tiny 1-Series is V2, the DA is V3)

[SpenceKonde]

-*9Downloaded. If I were you, I;d delete that for now. I'd try to trick someone someone else into releasing it - unless, of course, Microchip okays it. I could obliquely askmy microchip guy how the company would feel about that

Because they are fairly permissive. Like MicroUPDI firmware? That mEDBG, except that opened it in a hex editor and looked for an STS pointed at ADCSCRA (there was one, stored the value from register 16 there? Could be anyhing but.. what's this right before it? A load immediate to r16! So I just changed that value to it set the ADC to use Vdd as reference and we were rockin and rolling, and I DIDN'T have to make a mod fom hell between two pins of the QFN (There are a lot of parts I don't even bat an eye about, but 0.4mm pitch DFN, and then you need to wire on a jumper? No thanks. And microchip doesnt care about that

But they might care about QTouch. I've tried to reason out why it was secret

Either:

1. The code quality is so poor it would reflect poorly on the company (am told why they do not opensource the *edbgs. Then again the released what would become Serial UPDI with defalt settings that were under 1 k/s.
2. QTouch contains pieces copyrighted and licensed from others. It is illegal to open source it
3. QTouch would contain too much information about the internal implementation, not that this raises the bar for skill level needed to reverse engineer it all that much, and I question whether there's a swarm of competitors trying to reverse engineer qtouch

One thing worth noting is that @ladyada did this for the SAM parts, ro so I've been told (never owned any SAM parts. I have a board with no chip though:-(

Now it case 1, they wouuld be least likely to care becasue their code wouldn't be shared.

In case 2, proably not be concerned either. They';re not the ones releasing the potenialy encumbered IP without a license, and they have little incentivfe to tell the people who are shaking them down for royalties "hey, this guy over has worked around your patent. Indeed, they might have they'd have open sourced it if they weren't stuck with that license agreement. So they might welcome a "cleaned" implememntation of it. (rewritign software, as long as it's not too similar, gets around copyrightsn

se 3, though, they would bring down the hellfires upon you. I didn't think their ADC was very good compared t some more upmarket parts, I reckon it's case 1 or 2, and the company will let it fly but not endorse it unless you start trtying to make fat stacks 💰 with it. I'll ask some "purelty theoretical" questions to my guy on the inside, see if he gives me a sense that that would be... unwise or not. Personally, if I did this, and hadn't go a clear go-ahead from MC, I'd post it through as throoughly anonymized host as I could manage, or do the sort of "Get as many people onboard to take it up simultaneously, thaby the time their lawyers noticed and took action, the whole community would know. And be rightly pissed over it
someone got away with a t1616/3217only core that had objects generated with AS, and then headers he exracted - and from a business standpoint, it is of dubious sanity to harass your own customers who are trying to make your parts more widely useful :-P

[SpenceKonde]

but a cleanly reimplemented oner would be awesome imo better than getting a way to use the stock qtouch librries. I agree totally nobody is gong to be using for 2d surface. I do think people would want to do slider. We all know that Microchip's code quality standards leave something to be desired.

My biggest concern is how many of the latest parts haven't had it I wonder if it's on the Microchip Shit List next to external crystals..... (which they only seem to support when s major customer pistol whip's his sales rep and demands it) Has anything since the DA had it? (ie,does educated fuzzing of the relevant registers on parts that don't advertise it to shit?)

And yeah I'd deduced that the PTC involved a second ADC, I knew there was more to the 1+ series getting dual ADCs///

[MX682X]

I forgot to add, the license.h that comes with the atmel start generated code, only forbids to use the software with non-MC parts. Nothing about forbidding decompilation, so should be technically alright, but I'll try to stick with a "trial" version (note the naming ptc_touch instead of anything qTouch as qTouch is a trademark...). And the most interesting thing in my opinion, the harware capacitor compensation, is already documented here:
https://www.microchipdeveloper.com/touch:guide-to-interpret-cc-calibration-value

[MX682X]

My biggest concern is how many of the latest parts haven't had it

I think this is becaus ethey do a LOT of stuff for the PTC in hardware. And with the OPAMP and PGAs, they just didn't had the space anymore. Furthermore, I think they don't use DA, DB etc. as generation disambiguation but more of a feature set. each family has something the others don't.

Also Also, there might be a good chance that not many people were intrested in the touch functionality, especially since it required Atmel Start. It was always a hassle. And maybe there were some legal background rules that didn't allow Atmel ant then MC to publish anything after they bought the stuff.

[SpenceKonde]

And if you decompile that refactor so it's actually efficient, it will be essentially unrecognizable as their code ;-)

Regardign the user interface, I can't comment because there doesn't appear to be any documentation describing it,

[ladyada]

yes i re-engineered the QTouch for SAMD21 implementation - they left some debug symbols in and it was a pretty straightforward reverse engineer. nobody from MCP has ever cared or contacted us aobut it.
https://www.youtube.com/watch?v=T1EgC_NO6qs

[MX682X]

Alright then... I guess there shouldn't be much troubble adding this to megaTinyCore.
Features:

• Mutual- and Self-Cap support (switchable at runtime)
• auto calibration
• pseudo-simultanious use of ADC0.
• Works mostly "out-of-the-box" but supports similar adjusting options you can find in the qTouch-configurator.
• Samller Memory footprint compared to qTouch as it was written for the AVR CPU, core and gcc pointer arithmetic shortcomings in mind (e.g. use of _fastPtr, staticly linked list, 8-Bit variables preferred)

Features to be added in the future:

• Self-cap with shield
• combining multiple buttons
• use RTC and Event-System to allow wake-up from sleep.

I would prefer to add it to the megaTinyCore libraries, because this library only works on the 1-Series chips and because I have some pin lookup-tables that would fit perfectly into the pins_arduino.h file. Will be labeled as experimental in the Refs for now. I would make a PR if you don't mind it, Spence.
Oh, and as I only have the 1614s, I was only able to test it there, maybe you could test it on the bigger ones aswell? Should be easily portable though.
sketch_apr04a-008.zip

[SpenceKonde]

wait did you pull this off?

O_O

I'd add it it mTC if a library that works on 1-series parts can be provided, if Ladaada is doing it and getting away with it I figure I'm good. That would give us access to the last peripheral....

Note that said there's a PTC on the DA-series but.. none of the others. May not be worth reverse engineering that one.

You need hardware to test on? 0-1-2-series tinies? AVR128DB48/64? DA? DDs? An EA-28? Just lemme know man, you've beenthis repos MVP several seasons in a row.

[MX682X]

Well, I don't have anything explicit from MCP saying I was allowed to do what I did, but there was nothing that would have forbidden me from doing it (I didn't have to agree to anything to obtain the files), so it should be fine. besides, I'm targeting a "fair use" by providing only some functionaliy of the original qtouch library

And the testing is only needed on the x16 and x17 parts. No other Tiny Family has PTC

[ladyada]

neat :) @caternuson

[SpenceKonde]

Well, I don't have anything explicit from MCP saying I was allowed to do what I did, but there was nothing that would have forbidden me from doing it (I didn't have to agree to anything to obtain the files), so it should be fine. besides, I'm targeting a "fair use" by providing only some functionaliy of the original qtouch library

And the testing is only needed on the x16 and x17 parts. No other Tiny Family has PTC

email me your address and I'll make some parts for testing appear (note: the freebies you get for testing are the ones that are deemed non-salable for some reason, either because they're on an old rev of the board, or because they have had pins soldered onto them.)

[SpenceKonde]

DA will be getting some help from Microchip on this it sounds like over the summer. I'm debating what to do with the libraries - do I include them with the core? I feel like I almost already include too many libraries as part of the core. The DA library they'd prefer remain in their repo.

Will be fun to see how different the APIs are (I predict someone reading the API doc would be hard pressed to realize they were the same peripheral - like the two Flash.h's) and decide what to do about it. Changing assignee to you since it sounds like you plan to take the next move and I use this to plan what to prioritize

[SpenceKonde]

Oh - and there has never been a library I merged into this core from someone else that has had less than like 75% of the docs (re)written by me. In the cases where the writing style of the code author and myself is very different, it's pretty easy to tell who wrote which parts I think......

[MX682X]

It's nice to read that MC is doing something, because that will cetainly help to figure out some registers.
Except if it ends up as a wrapper for qTouch, because then there will be bloat, for example, it will have to bitwise OR uint64_t variables for the parts with more then 32 ptc pins to figure out the pin function overwrite register (at least that's what I think it is). And this will ultimately lead to me having to figure out the register map of the DA's, which, btw., seem to be similar to the SAMs, based on my notes and FreeTouch. It wouldn't be the only thing even, as they have also seem to have ported the internal VREG for the CPU from the SAMs to the Dx-Series.
Anyway, in conlclusion, it's better to wait for what MC will deliver, but based on what I have already seen code wise from them, I don't expect much AVR-nice code

[SpenceKonde]

Based on qtouch? Were you thinking we had a prayer of it not being based on the qtouch libraries? Whatever you've been smoking, pass it this way.

Of course it's gonna be based on qtouch. Why d you think that Microchip person a few months back PR'ed support for precompiled librariesinto the core?! Cause they're planning to bloody release libraries based on precompiled code and if you're doing that and you give that treatment to any precompiles code (as Microchip). Sounded like several, but they were written as college student (undergrad) capstone projects so I'll be managing expectations. And they need to of course be worked over by documentation (for readability - apparently the kids can't write for crap these days) and propaganda department (for unreadability of anything too revealing) to before public viewing, naturally.

But yeah I don'tthink this is going to end your quest for PTC support.

BTW - if you are intending to merge your evnetual library to both cores, make sure you're merging the same code and just different #ifdefs active - I like to be able to do merges between the files in the extras directory , not have to make changes to two files that I can't get a useful diff between. You'll notice many files are identical btween mTC and DxC.

[MX682X]

Based on qtouch? Were you thinking we had a prayer of it not being based on the qtouch libraries? Whatever you've been smoking, pass it this way.

There is a saying here: The ope dies last...

BTW - if you are intending to merge your evnetual library to both cores, make sure you're merging the same code and just different #ifdefs active - I like to be able to do merges between the files in the extras directory , not have to make changes to two files that I can't get a useful diff between. You'll notice many files are identical btween mTC and DxC.

Actually, i've been thinking about seperating the chip specific stuff like pinouts to two different files, but include them based on #ifdefs. similar to the io.h files and keep the actual code free of that for better readability.

Anyway, If you're intrested, I've opened up a repository already, but there are probably still some bugs, so I'm gonna need a bit more time. Get the examples ready, test the examples, expand the docs, etc. (in fact I was even working on making it more DA compatible) https://github.com/MX682X/ptc_touch

[SpenceKonde]

I'm going to move this to a discussion, as I don't think this is an actionable issue for me at the moemnt, so it should not be on my action item list.

[chipperdoodles]

Just throwing in on this discussion that with some help from @MX682X i've tested their library on a 3217 as well as a 1616 to pretty great initial success. I'm not technical enough to help sort out more technical things but so far i've had very good touch registration and ability to adjust gain in the case needing indirect contact with touch pads responding. It's all very exciting! and makes so much more possible with my big attiny based project.