Was ist bzw. war Atmel QTouch?

Meiner Meinung nach ist das eine Kombination aus Hard- und Software.

Ursprünglich war es eine reine Softwarelösung, die von einer separaten 
Firma für AVRs vermarktet worden ist. Dies war zu einer Zeit, als all 
diese Touch-basierten Telefone gerade erst aufkamen, folglich gab es 
einen großen Bedarf. Atmel hat dann die Lösung (und meiner Erinnerung 
nach auch das Entwicklungsteam) gekauft, und in der Folge wurden 
Hardwaremodifikationen erarbeitet, die QTouch unterstützen.

Diese Hardwareerweiterungen gab es anfangs auf speziellen Chips, später 
fanden sie Einzug in viele Atmel-MCUs, nicht nur AVRs sondern auch 
einige ARMs.

So findet sich beispielsweise im Datenblatt des SAM4S folgender Satz:

"It is possible to configure each input for the Schmitt trigger. By 
default the Schmitt trigger is active. Disabling the Schmitt trigger is 
requested when using the QTouch ® Library."

Den Sourcecode dafür hat man sicher teuer bezahlen müssen und mag ihn 
daher nicht rausrücken, auch wenn der Hype da drum inzwischen lange 
vorbei ist. Der Smartphone-Markt ist schnelllebig, die Hersteller 
schauen sich für jede neue Modellreihe stets neu um. Atmel hat damit mal 
kurzzeitig viel Geld machen können (und dafür sogar Lieferengpässe bei 
vielen anderen Kunden in Kauf genommen), aber inzwischen gibt's 
natürlich solche Lösungen von diversen Herstellern und ist kein 
Alleinstellungsmerkmal mehr.

>Marekting-Gewäsch
ich hoffe Marek ist nicht beleidigt

Manche PICs haben eine ähnlichee Touch-Hardware:
http://ww1.microchip.com/downloads/en/DeviceDoc/CTMU%2001375a.pdf
See What You Can Do with the CTMU
48 Anwendungsvorschläge, die letzten beiden lauten
Really Complex Applications
47.  Solving World Hunger
48.  Bring About World Peace
nur noch kurz die Welt retten

Arbeiter schrieb:
> Das ganze geht doch auch ohne teure Software

Naja, die ist dort einfach in den Chip eingepreist worden.

Danach kam man dann auf die Idee, dass man die Software auch separat 
vermarkten kann, da sich das Prinzip einfach in jeden AVR integrieren 
lässt.

Sieht mir auch gar nicht so aus, als würde die Library jetzt Geld 
kosten, sie ist halt nur nicht Opensource.

Jan schrieb:
> Wenn die bekannt wären, bräuchte man ja keine closed source lib mehr.

Kannst du probieren.

Vermutlich stecken da aber einige Mannjahre an Arbeit drin.

Da ich hier eine Tischlampe zu stehen habe, dessen Funktionalität etwas 
(..) verbesserungswürdig ist (sie vergisst die eingestellte Helligkeit 
ohne Versorgung) und die Bestückung auf den ersten Blick an Tiny24/44/84 
erinnerte, hab ich mir das Thema mal angeschaut:
- provisorisch 4 Sensorflächen in Kupferfolie auf Kunststoff geklebt und 
mit 2 Lagen Tesa umwickelt.
- eigene Körperkapazizät gegen Erde: etwa 150pF;
- hinter dem Sensor noch 50pF, das ist also die Kapazität der 
Kunststofffolie;
- Die 4 Sensoren kommen an Mega8 Eingänge, LEDs (gegen+) an die Ausgänge

1

  ldi  r16,low(ramend)

2

  ldi  r17,high(ramend)

3

  out  spl,r16

4

  out  sph,r17

5

  ser  r16

6

  out  ddrc,r16  ;Ausgänge für LED

7

8

loop:

9

  rcall  in_touch

10

  out  portc,r16

11

12

  ;Das Hauptprogramm hat auch was zu tun ...

13

  clr  r16

14

delay2:

15

  dec  r16

16

  brne  delay2

17

  rjmp  loop

18

19

in_touch:

20

  clr  r16

21

  out  ddrd,r16  ;Ausgänge loslassen

22

  ser  r16

23

  cli      ;nicht durch int stören!

24

  out  portd,r16  ;Pullups ein

25

  nop

26

  in   r16,pind  ;Abtasten nach 2 µs

27

  sei

28

  push  r16

29

30

  clr  r16

31

  out  portd,r16  ;Pullups wieder aus

32

  ser  r16

33

  out  ddrd,r16  ;Ausgänge wieder runterziehen

34

  pop  r16

35

  ret

Die Sensoren werden grundsätzlich auf Null gezogen, nur für die Abfrage 
auf die internen Pullups geschaltet, nach 2 Mikrosekunden (der Mega8 
läuft auf internem Takt 1 MHz), werden die Eingänge abgefragt, danach 
wieder genullt.
Ohne Betätigung, konnte die Eingangsspannung in dieser Zeit den 
Hi-Schwellwert erreichen, bei Betätigung (50pF am Eingang) wird Low 
gelesen.
Wenn der Käfer schneller als 1MHz läuft, müsste der NOP durch eine 
kleine Delay-Loop ersetzt werden.

Wichtig ist auch, dass die Schaltung nicht "in der Luft" hängt, sie 
braucht mindestens ein kleines kapazives Gegengewicht, beim Test, 470pF 
gegen Erde.

Leider stellte sich dann doch heraus, dass in meiner Lampe was Anderes 
verbaut ist :-(

c-hater schrieb:
> Viel ziemlich zeitkritisches Zeug.

Zeitkritisch sind nur die Zeilen zwischen CLI und SEI, also insgesamt 
3µS.
Selbst wenn das NOP wegen schnellerem Takt zu einer Schleife aufgeblasen 
werden muss, wird es bei 2µS bleiben.

1

 cli      ;bitte nicht stören!

2

 out  portd,r16  ;Pullups ein

3

 nop

4

 in   r16,pind  ;Abtasten nach 2 µs

5

 sei

c-hater schrieb:

> Dass die Hardwareregister nicht dokumentiert sind, macht die Sache zwar
> nicht gerade einfacher, andererseits ist's aber nicht so schlimm, wie
> man meinen könnte.
> ...
> Am Rest arbeite ich noch. Kann aber nicht mehr allzu lange dauern, bis
> ich von dieser elenden Lib endlich völlig unabhängig sein werde.

Bescheidene Frage: wurde daraus etwas, was man ansehen und verwenden 
kann? Ich beschäftige mich gerade etwas mit dem Thema und würde auch 
gerne von der aufgeblasenen, fast 8 kByte großen Originalversion 
wegkommen.

Anscheinend gab es unterschiedliche Implementationen von Qtouch.

Ich habe vor Jahren mal einen Ansatz implementiert, bei dem der 
Sample&Hold Kondensator des ADC genutzt wurde, um die Ladungs auf dem 
Touchpad zu sampeln. Damit kann man indirekt die Kapazität messen:

https://github.com/cpldcpu/TinyTouchLib

Tim  . schrieb:
> Anscheinend gab es unterschiedliche Implementationen von Qtouch.
>
> Ich habe vor Jahren mal einen Ansatz implementiert, bei dem der
> Sample&Hold Kondensator des ADC genutzt wurde, um die Ladung auf dem
> Touchpad zu sampeln. Damit kann man indirekt die Kapazität messen:
>
> https://github.com/cpldcpu/TinyTouchLib

Danke, habe ich gesehen und ich will mich damit auch mal näher befassen.

Es gibt auf Github offenbar mehrere Implementierungen nach dem gleichen 
Prinzip, ich habe mir das aber noch nicht alles im Detail angesehen. Man 
kann wohl davon ausgehen, dass Atmel es grundsätzlich genauso macht. 
Eine gute Beschreibung findet sich (auch) hier:

https://www.best-microcontroller-projects.com/arduino-capacitive-sensor.html

Meine Frage ging aber besonders an c-hater (und vielleicht andere, die 
ähnliches herausgefunden haben), nämlich welche besondere 
Hardware-Unterstützung in den neueren Atmel-Chips enthalten ist und wie 
man diese anspricht (und natürlich ob er bereit ist, dieses Wissen mit 
uns zu teilen). Wenn ich bedenke, wie kurz die hier diskutierten 
Lösungen sind, will es mir überhaupt nicht in den Kopf, warum 
Atmel/Microchip trotz "optimierter" Hardware-Unterstützung nahezu 8 
kByte für die QTouch-Library benötigt. Ich denke, das kann man auch 
wesentlich kürzer schreiben. Um die Qualität der Touch-Erkennung 
miteinander zu vergleichen, wäre es dann allerdings schon wünschenswert, 
die gleichen Mittel einsetzen zu können.

Anbei mal ne einfache Touchlib mit dem ADC auf dem ATmega48.
Es werden 2 Tasten definiert an ADC4 und ADC5. Es lassen sich leicht 
weitere Tasten hinzufügen (case 2..n).
Nach dem Einschaltreset läuft der ADC-Interrupt für 20ms und dann werden 
die Meßwerte als Schwellwert + 10 gespeichert. Die Schwellwerte werden 
also automatisch ermittelt. Der ADC ist unempfindlich gegen Temperatur- 
und VCC-Schwankungen.
Nach dem Einlesen folgt dann meine übliche Entprell-Lib. Die 10ms werden 
mit über den ADC-Interrupt eingestellt.

So, ich habe jetzt mal eine Test-Version für ATtiny Serie 0/1 
geschrieben, etwas allgemeiner gehalten, damit sie für alle Prozessoren 
dieser Serien und weitgehend beliebige Touch-Button-Konfigurationen 
einfach anpassbar sein sollte. "Sollte" heißt, dass ich das bisher nur 
mit einem ATtiny817 Xplained pro Board mit 2 Buttons getestet habe und 
allgemein noch Fehler drin sein können.

Angeguckt habe ich mir das Signal per Atmel Data Visualizer. Auffällig 
ist, dass das Signal im nicht-aktiven Zustand bei etwa 700 +/- 50 liegt 
und im aktiven Zustand etwa 80 bis 100 darüber (ADC-max 1023). Das hätte 
ich so nicht unbedingt erwartet, mit den originalen QTouch-Routinen ist 
das Ruhesignal kleiner und der Signalhub größer. Anscheinend findet da 
eine interne Verstärkung statt und/oder die Sample-Kapazität ist größer 
als beim reinen ADC-Betrieb.

Mit Datastreamer braucht das Ganze gut 1 kByte, ist natürlich nicht 
annähernd so funktionsreich wie bei Atmel, scheint aber genau so stabil 
zu laufen, jedenfalls bei mir im Selbstversuch.

Frage insbesondere an Tim und Peter D.;

sind das (700 bis knapp 800) zu erwartende Werte? Oder habt ihr mit 
euren Implementierungen ganz andere Resultate?

Vielleicht meldet sich ja auch noch c-hater?

Schade, bisher nichts mehr gekommen. Ich hätte vor allem gerne von 
c-hater erfahren, was er herausgefunden hat. Leider ist er aber nicht 
für eine direkte Kommunikation erreichbar, und so bleibt es wohl sein 
Geheimnis.

Ich hab mein bisheriges Ergebnis mal hier gepostet:

https://www.avrfreaks.net/forum/capacitive-touch-without-q-attiny-series-01

> Frage insbesondere an Tim und Peter D.;
>
> sind das (700 bis knapp 800) zu erwartende Werte? Oder habt ihr mit
> euren Implementierungen ganz andere Resultate?

Ich weiss ehrlich gesagt nicht mehr, welche Werte typisch waren. 
Allerdings hängt das natürlich auch von der Kapazität (bzw. den 
Dimensionen) Deines Touchpads und auch dem Timing ab.

Man könnte mit Hilfe des Analogkomparators und einem externen Widerstand 
auch einen Relaxationsoszillator aufbauen, mit dem man die Kapazität des 
Touchpads über die Frequenz auslesen kann. Mit den neueren ATtiny kann 
das vielleicht auch die Peripherie ohne Hilfe der MCU? (Über die CCB 
oder das Reflexsystem).

Tim  . schrieb:
> Man könnte mit Hilfe des Analogkomparators und einem externen Widerstand
> auch einen Relaxationsoszillator aufbauen, mit dem man die Kapazität des
> Touchpads über die Frequenz auslesen kann. Mit den neueren ATtiny kann
> das vielleicht auch die Peripherie ohne Hilfe der MCU? (Über die CCB
> oder das Reflexsystem).

Unter der Annahme eines "idealen" Ladungstransfers, also verlustfreie 
Übertragung der Ladung vom Touchpad zur Parallelschaltung von Touchpad + 
Sampling-Kondensator, lässt sich das leicht ausrechnen. Ich komme damit 
auf 20 bis 25 pF auf dem ATtiny-Evaluation-Board. Das scheint mir 
realistisch. Interessanterweise gibt die originale QTouch-Software auch 
eine errechnete Kapazität aus. Die ist erstens etwas höher und mir ist 
zweitens völlig unklar, wie die errechnet wird.

Wie auch immer, die selbstgemachte Version per Umladen mit dem 
Sampling-Kondensator des A/D-Wandlers scheint gut zu funktionieren, ist 
aber weniger empfindlich als Original QTouch. Atmel/Microchip macht da 
offenbar noch mehr, weshalb es schon interessant wäre, wie man da 
rankommt.

Dieter R. schrieb:
> Wie auch immer, die selbstgemachte Version per Umladen mit dem
> Sampling-Kondensator des A/D-Wandlers scheint gut zu funktionieren, ist
> aber weniger empfindlich als Original QTouch. Atmel/Microchip macht da
> offenbar noch mehr, weshalb es schon interessant wäre, wie man da
> rankommt.

Hast Du mal ein Oszilloskop 'drangehalten?

Was fehlt denn bei Deiner Implementierung - Auflösung oder SNR?

Tim  . schrieb:

> Was fehlt denn bei Deiner Implementierung - Auflösung oder SNR?

Erstmal fehlt gar nichts, es läuft 1A und jedenfalls mit dem Demo-Board 
(eigenes Board habe ich dafür noch nicht, ist aber gerade in China in 
Produktion) stabil auf +/- 1 count.

Definitiv geht mit Original-QTouch aber mehr. Das kann man so 
parametrieren, dass es auch mit mehreren Millimeter 
Kunststoff-Frontplatte dazwischen noch läuft. Das geht mit der einfachen 
Umlade-Methode nicht, dafür ist die nicht empfindlich genug. Offenbar 
sind in der Original-Implementierung also noch weitere Features 
enthalten, die uns unwissenden Endbenutzern nicht zugänglich sind. 
Offizielle Dokumentation dazu gibt es ja nicht. Drum hätte mich 
interessiert, was c-hater herausgefunden hat. Der erzählt zwar, dass er 
was weiß, macht aber auch ein Geheimnis daraus.

c-hater schrieb:
> Lib selber in ihrer aktuellen Inkarnation für echte Q-Touch-Devices
> überhaupt nichts mehr in Richtung Signalverarbeitung oder Pinwackeln
> tut. Das macht alles die (bis auf die Tatsache ihrer Existenz
> undokumentierte) Q-Touch-Hardware.

Das klingt jetzt aber schon interessant. Das heisst, es gibt 
undokumentierte Register im I/O Bereich der unterstützenden MCUs?

Warum willst Du die Ergebnisse nicht veröffentlichen? NDA?

c-hater schrieb:
> die Hardwareregister nicht dokumentiert sind

Das klingt nach Märchenonkel und ist sehr unwahrscheinlich!

c-hater schrieb:
> Dieter R. schrieb:
>
>> Definitiv geht mit Original-QTouch aber mehr. Das kann man so
>> parametrieren, dass es auch mit mehreren Millimeter
>> Kunststoff-Frontplatte dazwischen noch läuft. Das geht mit der einfachen
>> Umlade-Methode nicht, dafür ist die nicht empfindlich genug. Offenbar
>> sind in der Original-Implementierung also noch weitere Features
>> enthalten, die uns unwissenden Endbenutzern nicht zugänglich sind.
>> Offizielle Dokumentation dazu gibt es ja nicht. Drum hätte mich
>> interessiert, was c-hater herausgefunden hat. Der erzählt zwar, dass er
>> was weiß, macht aber auch ein Geheimnis daraus.
>
> Nein, ...

Worauf genau bezieht sich dein "Nein"? Dieses hier:

"Das kann man so parametrieren, dass es auch mit mehreren Millimeter 
Kunststoff-Frontplatte dazwischen noch läuft."

habe ich jedenfalls (mit freundlicher Hilfe des Microchip-Supports) so 
hingekriegt, mit on-the-fly modifizierbaren Parametersätzen. Was sich 
dabei tut, weiß ich natürlich nicht, ich habe nur die passenden 
Parameter eingestellt. Mit dem einfachen Umladen auf den 
Sampling-Kondensator ist das nicht empfindlich genug, jedenfalls nicht 
nach meinen bisherigen Versuchen. Gleiches gilt für das (extrem 
nützliche) "Driven Shield" Feature. Ich hätte jetzt keine Idee, wie ich 
das ohne Zugriff auf zusätzliche Hardware im Chip realisieren könnte.

> Im Übrigen: selbst wenn ich irgendwann mal damit ganz fertig werden
> sollte, werde ich das Ergebnis mit an Sicherheit grenzender
> Wahrscheinlichkeit nicht veröffentlichen. Jedenfalls nicht hier.

Das "nicht hier" kann ich zu einem gewissen Maße ja nachvollziehen. 
Grundsätzlich wäre es aber schade, wenn du dein Wissen nicht auch 
anderen zur Verfügung stellen könntest bzw. würdest.

Also so geheimnisvoll ist das alles nicht. Im ATtiny817 Datenblatt steht 
das meiste, bzw. ist verlinkt.

 - Qtouch nutzt die ADC Hardware
 - Als Zusatzfunktion gibt es eine Offsetcancellation, die auf 
irgendeine Art die Kapazität des Touchpads kompensiert. Damit steigt 
natürlich die effektive Auflösung. Das SNR wird aber wohl nicht besser.
 - Anscheinend gibt es eine zusätzliche State-machine, den PTC 
(Peripheral Touch Controller), die die Kontrolle über den ADC übernimmt.
 - Die I/O Addressen des PTC sind nicht dokumentiert.
 - Atmel Start unterstützt Qtouch und ist ohne NDA verfügbar. Demnach 
müsste man sich nur die Binaries anschauen...

Apollo M. schrieb:
> c-hater schrieb:
>> die Hardwareregister nicht dokumentiert sind
>
> Das klingt nach Märchenonkel und ist sehr unwahrscheinlich!

nah...

Apollo M. schrieb:
> c-hater schrieb:
>> die Hardwareregister nicht dokumentiert sind
>
> Das klingt nach Märchenonkel und ist sehr unwahrscheinlich!

Sorry, können nicht die, die überhaupt keine Ahnung vom Thema haben, 
einfach mal die Klappe halten!? Ich kann schon verstehen, dass andere, 
c-hater eingeschlossen, sich mit diesen ewigen unqualifizierten Flame 
Wars in diesem Forum nicht auseinandersetzen wollen.

Für SACHDIENLICHE (ganz dick und fett geschrieben) Beiträge wäre ich 
aber immer noch extrem dankbar.

Tim  . schrieb:
> Also so geheimnisvoll ist das alles nicht. Im ATtiny817 Datenblatt steht
> das meiste, bzw. ist verlinkt.

Ja, und da fängt das Problem schon an. Es gibt unzählige Beschreibungen 
von Atmel/Microchip. Steigt man tiefer darin ein, stellt man fest, dass 
das meiste auf die aktuelle Implementierung nicht wirklich übertragbar 
ist, jedenfalls geht es mir mit meinem bescheidenen Durchblick so. 
Support-Anfragen an Microchip (ich hatte das jetzt mehrere Male) enden 
jedesmal nach ca. zweiwöchigem Hin und Her mit einer tatsächlich 
hilfreichen Auskunft. Meine generelle Frage, wo das denn dokumentiert 
ist, wurde allerdings noch niemals beantwortet.

Die in der von dir gezeigten Grafik genannte Struktur samt angegebener 
Variable zur Bestimmung der Kompensationskapazität finde ich in der 
aktuellen QTouch-Lib auch nicht. Kann natürlich sein, dass ich gerade 
ein Brett vorm Kopf habe.

Dieter R. schrieb:
> Die in der von dir gezeigten Grafik genannte Struktur samt angegebener
> Variable zur Bestimmung der Kompensationskapazität finde ich in der
> aktuellen QTouch-Lib auch nicht. Kann natürlich sein, dass ich gerade
> ein Brett vorm Kopf habe.

http://ww1.microchip.com/downloads/en/DeviceDoc/atmel-42195-qtouch-library-peripheral-touch-controller_user-guide.pdf

Seite 14

Tim  . schrieb:

> 
http://ww1.microchip.com/downloads/en/DeviceDoc/atmel-42195-qtouch-library-peripheral-touch-controller_user-guide.pdf
>
> Seite 14

Soweit die Beschreibung: "The tag_touch_measure_data_t structure ...".

Zitat aus meiner IDE:

Find all "tag_touch_measure_data_t", Subfolders, Find Results 1, "Entire 
Solution ( Including External Items )", ""
  Matching lines: 0    Matching files: 0    Total files searched: 66

Vielleicht bin ich heute ja wirklich zu blöd zum Suchen bzw. Finden, 
aber mehr kommt bei mir nicht raus.

http://ww1.microchip.com/downloads/en/AppNotes/01298A.pdf

Hugo H. schrieb:
> http://ww1.microchip.com/downloads/en/AppNotes/01298A.pdf

Das ist ja drollig. Das ist Charge Transfer, aber umgekehrt. Erst wird 
der (kleine, ca. 10 pF) Sampling-Kondensator aufgeladen und dann mit dem 
Touchpad (größere Kapazität, ca. 20 pF oder mehr) parallelgeschaltet. 
Ich würde erwarten, dass das die Nachteile aller Verfahren miteinander 
vereint, weil nur etwa halb so viel (oder noch weniger) Energie im 
System steckt und damit die Störanfälligkeit höher ist.

Überschlägiges Nachrechnen (wenn ich jetzt keinen Fehler gemacht habe) 
ergibt, dass die Signaldifferenz zwischen Referenzwert und aktivem Touch 
für beide Versionen gleich ist. Bloß wird in der einen Version das 
Signal größer beim Touch, in der anderen kleiner. In der einen steckt 
mehr Energie im System, in der anderen weniger.

Ich bin mir nicht sicher, ob ich das jetzt auch noch ausprobieren soll. 
Hat jemand anders Lust dazu???

Immerhin beruhigt es in anderer Weise, Zitat:

"The Capacitive Voltage Divider method provides an
easy way to add capacitive touch sensing to Microchip
PIC devices which do not have touch sensing
peripherals, like the CSM or CTMU. It also allows for
very fast sampling times. The key peripheral required is
an ADC and I/O to perform the touch sensing function."

Das heißt, Microchip gibt dem Anwender ausdrücklich frei, eine 
"Capacitive Voltage Divider method " zu verwenden. Keine möglichen 
IP-Konflikte, kann man also ohne Bedenken kommerziell einsetzen, das ist 
erfreulich.

Interessant ist noch ein Hinweis: "While sensors are not being scanned, 
they should be kept at ground or VDD." Das habe ich bisher nicht 
bedacht.

Tim  . schrieb:
> Apollo M. schrieb:
>> c-hater schrieb:
>>> die Hardwareregister nicht dokumentiert sind
>>
>> Das klingt nach Märchenonkel und ist sehr unwahrscheinlich!

Ich leiste Abbitte, ich wollte es nicht glauben!
Aber es stimmt, die Register sind nicht definiert.
Das war für mich undenkbar.

Apollo M. schrieb:
> Aber es stimmt, die Register sind nicht definiert.
> Das war für mich undenkbar.

Atmel hat da immer ein viehisches Gewese drum gemacht.

Der ganze Touch-Kram war für sie mal melkende Kuh, weil irgendein 
Smartphone-Hersteller für eine seiner Produktserien auf den Zug 
aufgesprungen war. Da wurden dann ggf. auch andere Produktionen 
gedrosselt, Hauptsache man konnte dahin genügend "Q Touch" verscherbeln. 
Da das Ganze am Ende ein Mix aus Hard- und Software geworden ist, hat 
man halt beides gemeinsam dann als Blackbox vermarktet.

Nur: in diesem volatilen Mobiltelefon-Geschäft wird von Runde zu Runde 
neu ausgekungelt, bei wem man einen Groschen mehr sparen kann. In der 
nächsten Runde war Atmel dann nicht mehr mit dabei. Damit hätte man 
eigentlich jetzt den Touch-Kram auch freigeben können, denn es ist 
seither kein Wettbewerbsvorteil mehr. Hat man aber halt nicht, und so 
isses nun auch 10 Jahre später noch eine undokumentierte Blackbox. 
Inzwischen kann es vermutlich auch keiner mehr dokumentieren, weil die 
Entwickler von damals zum großen Teil nicht mehr da sind.

Jörg W. schrieb:

> Inzwischen kann es vermutlich auch keiner mehr dokumentieren, weil die
> Entwickler von damals zum großen Teil nicht mehr da sind.

Dann sind jetzt wohl neue dran, Atmel bzw. jetzt Microchip hat vom 
damaligen Geschäft vielleicht immer noch genug Geld übrig (oder 
unterbeschäftigte Entwickler ;-)

Jedenfalls ändern die alle paar Monate mal wieder was in ihrem 
Monster-Code, und die indischen Supportmitarbeiter scheinen das sogar 
mitzukriegen. Bloß die aktuelle Dokumentation dazu, die gibt's nicht.

Jörg W. schrieb:
> Meiner Meinung nach ist das eine Kombination aus Hard- und
> Software.

Bei den neueren MC's ja, bei den älteren wohl reine SW. Man kann sich 
aber viele Brosamen zusammen suchen - z. B.

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42230-QTouch-Safety-Library-Peripheral-Touch-Controller_User-Guide.pdf

ist ganz interessant und hier

http://ww1.microchip.com/downloads/en/DeviceDoc/40001912A.pdf

auf Seite 383 bekommt man zumindest einen schematischen Überblick.

Wenn man in das Studio 6 zurück geht kann man sich auch ein paar 
Code-Schnipsel anschauen (für die älteren MCs).

Hugo H. schrieb:
> http://ww1.microchip.com/downloads/en/DeviceDoc/40001912A.pdf

Da steht ja, daß der ADC nicht mehr für die Applikation verfügbar ist:
"When the Peripheral Touch Controller (PTC) is enabled, ADC0 is fully 
controlled by the PTC peripheral."

Eine selbst geschriebene Lib hat daher den Vorteil, daß freie 
ADC-Eingänge weiterhin ausgelesen werden können.

Wer will, kann ja mal die Lib aus Atmel|START einbinden und dann im 
Debugger durchsteppen. Der Simulator wird wohl die neueren AVRs nicht 
können.

Soul E. schrieb:
> Guck Dir die alten Versionen an, z.B. die Atmel QTouch Library 4.3 von
> 2010. Da sind die Algorithmen ganz gut beschrieben, und der
> Assemblercode ist auch einigermaßen kommentiert.

Ich komme noch mal auf diesen alten Beitrag zurück. Hat jemand den 
erwähnten kommentierten Assemblercode? Ich kann ihn mit Google nicht 
finden. Ich finde nur die üblichen API-Beschreibungen.

Dieter R. schrieb:
> Hat jemand den
> erwähnten kommentierten Assemblercode?

Hälst Du das für "gut nachvollziehbar" und kommentiert?

1

#else

2

GLOBAL_FUNCTION _1101010111_

3

_1101010111_:

4

    out  REG( DDR, SNSK1 ), p_4

5

    out  REG( DDR, SNS1 ), p_1

6

#if (QT_DELAY_CYCLES == 1)  

7

#elif (QT_DELAY_CYCLES == 2)

8

    _00011001_

9

#elif (QT_DELAY_CYCLES == 3)

10

    _00011001_

11

    _00011001_

12

#elif ((QT_DELAY_CYCLES - 1) - (3 * ((QT_DELAY_CYCLES - 1)/3)) == 0)

13

    _11100011_

14

    _10100011_

15

    _01101001_

16

#elif ((QT_DELAY_CYCLES - 1) - (3 * ((QT_DELAY_CYCLES - 1)/3)) == 1)

17

    _11100011_

18

    _10100011_

19

    _01101001_

20

    _00011001_

21

#else

22

    _11100011_

23

    _10100011_

24

    _01101001_

25

    _00011001_

26

    _00011001_

27

#endif

28

    out  REG( DDR, SNS1 ), p_2

29

    out  REG( DDR, SNSK1 ), p_3

30

    nop

31

    in   r_v, REG( PIN, SNS1 )

32

    and  r_v, p_5

33

    ret

34

#endif

Hugo H. schrieb:
>
> Hälst Du das für "gut nachvollziehbar" und kommentiert?
> ...

Ehrlich gesagt kann ich mit dem Schnipsel nichts anfangen. Da fehlen mir 
mehrere Seiten Kontext.

Dieter R. schrieb:
> Ehrlich gesagt kann ich mit dem Schnipsel nichts anfangen

Genau so sieht der Rest auch aus. Ich möchte hier nicht gegen 
irgendwelches Copyright verstoßen ...

Ergo:

Dieter R. schrieb:
> die Atmel QTouch Library 4.3 von
>> 2010. Da sind die Algorithmen ganz gut beschrieben, und der
>> Assemblercode ist auch einigermaßen kommentiert.

Quackes.

Ich habe jetzt mal ein Oszilloskop drangehängt, alles mit dem Evaluation 
Board und einmal Original Qtouch in der Standard-Konfiguration, so wie 
Atmel Start das ausspuckt, und zum anderen mit meinem eigenen Code mit 
zyklischer Abfrage alle 2 Millisekunden pro Touch Button.

QT-Ttest.jpg: Datastreamer, für beide Varianten gleich konfiguriert, 
erst betrieb mit QTouch, zyklisch Button betätigt, dann eigenen Code 
geladen und noch mal draufgedrückt (hat nicht ganz geklappt). Man sieht, 
dass Qtouch ein viel größeres Signal produziert, wobei die 
Standard-Einstellung keinesfalls ausgereizt ist, da ist noch viel 
reserve zur Empfindlichkeitserhöhung.

QT-cycle.png: zyklische Abfrage alle 20 ms
QT-pulse_chain.png: eine komplette Abfrage, man sieht eine Kette von 16 
Impulsen
QT-detail.png: einzelne Abfrage (Touch-Button berührt), offenbar wird 
die Touch-Elektrode erst auf Vcc geladen, dann umgeladen und gemessen, 
dann entladen auf Gnd, dann wieder umgeladen und gemessen - dieser 
Zyklus erfolgt 16 mal. Die Spannung nach dem Umladen erhöht (von Vcc 
aus) bzw. erniedrigt sich (von Gnd aus) bei Berührung, so wie man das 
auch erwarten würde. Dazwischen sind allerdings noch gleichlange 
Abschnitte mit konstanter (halber) Spannung. Wie die erzeugt werden, ist 
mir unklar, das erklärt sich wohl nur durch die spezielle 
QTouch-Hardware.

Der ADC wird dabei anscheinend außerhalb seiner offiziellen 
Spezifikation betrieben. Die maximale ADC-Clock beträgt offiziell 1,5 
MHz, mit 10 MHz CPU-Clock wären 1,25 MHz möglich. das ergibt für jede 
der 6 sichtbaren Phasen 5 ADC-Clock. Eine Wandlung dauert aber schon 13 
Clocks + Overhead.

touch-cycle.png: die schlichte eigene Version, Abfrage alle 2 ms
touch-pulse.png: Detail, erst auf Vcc, dann umladen und messen.

c-hater schrieb:
> Könnte z.B. sein, dass der PTC gar nicht direkt schuld ist, sondern ein
> Bug oder Sparmaßnhmen im Multiplexer diese Sache bewirkt.

Mir scheint, bei neueren AVR ist tatsächlich ein (undokumentierter) Teil 
in der HW abgebildet - aus Kompatibilitätsgründen hat man für ältere AVR 
diese Funktionalität mit der "ursprünglichen" Lib realisiert.

Hugo H. schrieb:

> Genau so sieht der Rest auch aus. Ich möchte hier nicht gegen
> irgendwelches Copyright verstoßen ...

Gegen ein Copyright wirst du schwerlich verstoßen können, allenfalls 
gegen Lizenzbestimmungen. Wie sehen die denn aus? Bei der aktuellen 
Version steht kurz und knapp:

"Subject to your compliance with these terms, you may use Microchip 
software and any derivatives exclusively with Microchip products. It is 
your responsibility to comply with third party license terms applicable 
to your use of third party software (including open source software) 
that may accompany Microchip software."

Kurzfassung: Keine Beschränkung der Weitergabe (da ist überhaupt nichts 
geregelt), Benutzung nur mit Microchip-Produkten. Genau darum dreht es 
sich hier ja.

> Mir scheint, bei neueren AVR ist tatsächlich ein (undokumentierter) Teil
> in der HW abgebildet - aus Kompatibilitätsgründen hat man für ältere AVR
> diese Funktionalität mit der "ursprünglichen" Lib realisiert.

Ich habe den starken Eindruck, dass unter dem Label "QTouch" ganz 
verschiedene Dinge vermarktet wurden und werden. Aktuell unter 
Verwendung einer speziellen Konfiguration des ADC, früher ganz anders. 
Kompatibel ist da nichts, auch die APIs sind nur ungefähr ähnlich.

c-hater schrieb:
> Bei der absolut lausigen Qualität der MC-Datenblätter muss man leider
> jederzeit auch mit sowas rechnen...

Ernsthaft? Ich halte die ex-Atmel DB immer noch mit für die besten. Die 
von MS sind allerdings tatsächlich sehr gewohnungsbedürftig.

Dieter R. schrieb:
> Der ADC wird dabei anscheinend außerhalb seiner offiziellen
> Spezifikation betrieben. Die maximale ADC-Clock beträgt offiziell 1,5
> MHz, mit 10 MHz CPU-Clock wären 1,25 MHz möglich. das ergibt für jede
> der 6 sichtbaren Phasen 5 ADC-Clock. Eine Wandlung dauert aber schon 13
> Clocks + Overhead.

Evtl. wird nicht jedes sample direkt konvertiert, sondern es gibt noch 
eine analoge Vorprozessierung.

Dieter R. schrieb:
> Gegen ein Copyright wirst du schwerlich verstoßen können

das sehe ich anders:

/*********************************************************************** 
********
*   $FILE:  qt_asm_tiny_mega.S
*   Atmel Corporation:  http://www.atmel.com \n
*   Support email:  touch@atmel.com
************************************************************************ 
******/

/*  License
*   Copyright (c) 2010, Atmel Corporation All rights reserved.
*
*   Redistribution and use in source and binary forms, with or without
*   modification, are permitted provided that the following conditions 
are met:
*
*   1. Redistributions of source code must retain the above copyright 
notice,
*   this list of conditions and the following disclaimer.
*
*   2. Redistributions in binary form must reproduce the above copyright 
notice,
*   this list of conditions and the following disclaimer in the 
documentation
*   and/or other materials provided with the distribution.
*
*   3. The name of ATMEL may not be used to endorse or promote products 
derived
*   from this software without specific prior written permission.
*
...

Hugo H. schrieb:
> *   2. Redistributions in binary form must reproduce the above copyright
> notice,
> *   this list of conditions and the following disclaimer in the
> documentation

Ich sehe da keine reverse engineering clause oder ähnliches. Die 
Dokumentation der Hardware anhand der Library und anschließende 
Clean-Room Reimplementierung sollte möglich sein.

Tim  . schrieb:
> Hugo H. schrieb:

> Ich sehe da keine reverse engineering clause oder ähnliches. Die
> Dokumentation der Hardware anhand der Library und anschließende
> Clean-Room Reimplementierung sollte möglich sein.

Vor allem ist: "Redistribution ... in source ... forms ... permitted". 
Das war ja wohl seine Sorge. Und auch "modifications" sind gestattet. 
Also, was solls.

Hugo H. schrieb:
> *   1. Redistributions of source code must retain the above copyright
> notice,

Dieter R. schrieb:
> Vor allem ist: "Redistribution ... in source ... forms ... permitted".
> Das war ja wohl seine Sorge. Und auch "modifications" sind gestattet.
> Also, was solls.

Lesen - verstehend - kannst Du? Falls nicht - Google Sprachtools o. ä. 
(hilft aber nicht beim Verstehen).

Tim  . schrieb:
> Ich sehe da keine reverse engineering clause oder ähnliches.

Ja, mach mal. Ist in der Tat nicht verboten (soweit ich das erkennen 
kann). Wir sind wohl alle gespannt auf Deine Ergebnisse.

Was hat das mit der Veröffentlichung des (vermutlich reassemblierten 
oder anonymisierten) Source-Codes zu tun?

Dieter R. schrieb:
> Also, was solls.

Yep - dann besorge Dir die

Dieter R. schrieb:
> Atmel QTouch Library 4.3

und lege los. Kannst die ja auch für alle hier veröffentlichen, spricht 
auch Deiner Sicht ja wohl nichts dagegen.

Anscheinend geht es wohl um diesen Source, der vielfach im Internet zu 
finden ist?

https://github.com/jgillick/AVR-Libs/tree/master/QTouch/QTouch

Tim  . schrieb:
> Anscheinend geht es wohl um diesen Source, der vielfach im Internet zu
> finden ist?
>
> https://github.com/jgillick/AVR-Libs/tree/master/QTouch/QTouch

Scheint so, danke. Viele interessante Kommentare in der 
Assembler-Source. Und nützt offenbar nichts für die aktuelle 
Betrachtung, schon der unter "Setup" erwähnte 20nF-Kondensator spricht 
dafür, dass es die ganz anders funktionierende Uralt-Version mit 
sukzessiver Aufladung per Ladungspumpe ist (hat das Prinzip einen 
richtigen Namen?). Immerhin belegt es, dass damals alles ganz anders 
war.

Bei der 4.3 scheint es sich um einen anderen Ansatz zu handeln: Kein 
charge-sharing mit dem ADC S&H, sondern aufsummieren von Ladung auf 
einem externen Kondensator.

Der code scheint u.A. deswegen so kryptisch auszusehen, da er sehr 
konfigurierbar ist. Die Optionen werden durch den Präprozessor zu diesen 
Binärcodes zusammengesetzt. Allerdings sind es teilweise auch Defines 
für zyklengenaue Delay-Funktionen.

Ich glaube es wäre fast einfacher das listing-File einer spezifischen 
Konfiguration auszuwerten, als sich durch dieses Durcheinander zu 
wühlen. Ich frage mich, wie sie das eigentlich bei Atmel gepflegt haben.

Leider lernt man nichts über die PTC Hardware. Die Methode ist auch 
interessant, aber wahrscheinlich wäre es einfacher, diese ohne Analyse 
der QTouch lib nachzubauen.

Hugo H. schrieb:

> Wir sind wohl alle gespannt auf Deine Ergebnisse.

Kannst du dir ansehen, hatte ich bereits gepostet, Sources verfügbar und 
ausgiebig kommentiert. Inzwischen noch erweitert auf die erwähnte 
Empfehlung, die Touch-Elektroden auf definiertem Pegel zu halten. Das 
kann aber jeder leicht selbst anpassen, außerdem hält sich Atmel selbst 
nicht daran, wie man mit dem Oszilloskop sehen konnte.

Allerdings sieht man daraus auch die Begrenzungen des simplen 
Charge-Transfer-Verfahrens und wie reiz- und sinnvoll ein eigener 
Zugriff auf die QTouch-Hardware wäre.

c-hater schrieb:
> Ähem... Was soll "anonymisierter Code" sein?

Hugo H. schrieb:
> #else
> GLOBAL_FUNCTION _1101010111_
> _1101010111_:
>     out  REG( DDR, SNSK1 ), p_4
>     out  REG( DDR, SNS1 ), p_1
> #if (QT_DELAY_CYCLES == 1)
> #elif (QT_DELAY_CYCLES == 2)
>     _00011001_
> #elif (QT_DELAY_CYCLES == 3)
>     _00011001_
>     _00011001_

Das - oder glaubst Du jemand schreibt so etwas, damit es nachvollziehbar 
ist?

Tim  . schrieb:
> Anscheinend geht es wohl um diesen Source, der vielfach im Internet zu
> finden ist?

Ja, ich habe den nicht veröffentlicht. Und, bringt der etwas?

Dieter R. schrieb:
> Und nützt offenbar nichts für die aktuelle
> Betrachtung,

Ja - wie schon geschrieben.

Dieter R. schrieb:
> Kannst du dir ansehen, hatte ich bereits gepostet

Wo? Link?

Hugo H. schrieb:
> Dieter R. schrieb:
>> Kannst du dir ansehen, hatte ich bereits gepostet
>
> Wo? Link?

Weiter oben. Du kannst doch so gut mit Suchmaschinen umgehen.

Dieter R. schrieb:
> Ich komme noch mal auf diesen alten Beitrag zurück. Hat jemand den
> erwähnten kommentierten Assemblercode? I

Dieter R. schrieb:
> Hugo H. schrieb:
>
>> Wir sind wohl alle gespannt auf Deine Ergebnisse.
>
> Kannst du dir ansehen, hatte ich bereits gepostet, Sources verfügbar und
> ausgiebig kommentiert.

Liest Du eigentlich, was Du so schreibst?

Hugo H. schrieb:
> Tim  . schrieb:
>> Ich sehe da keine reverse engineering clause oder ähnliches.
>
> Ja, mach mal. Ist in der Tat nicht verboten (soweit ich das erkennen
> kann). Wir sind wohl alle gespannt auf Deine Ergebnisse.

Wieso antwortest Du auf Fragen an Tim  . (cpldcpu)18.02.2022 18:07.

Hast Du 2 Accounts?

sigh was eigentlich immer das unproduktivie Debattieren hier?

Ok, ich habe einfach mal eines der QTouch-Beispiele für den ATtiny817 
compiliert. Das Listingfile mitsamt Funktionsnamen ist direkt verfügbar.

Da haben wir z.B. das hier:

1

000015b6 <qtm_ptc_start_measurement_seq>:

2

    15b6:  61 15         cp  r22, r1

3

    15b8:  71 05         cpc  r23, r1

4

    15ba:  91 f1         breq  .+100      ; 0x1620 <qtm_ptc_start_measurement_seq+0x6a>

5

    15bc:  00 97         sbiw  r24, 0x00  ; 0

6

    15be:  81 f1         breq  .+96       ; 0x1620 <qtm_ptc_start_measurement_seq+0x6a>

7

    15c0:  20 91 65 3e   lds  r18, 0x3E65  ; 0x803e65 <touch_seq_lib_state>

8

    15c4:  22 23         and  r18, r18

9

    15c6:  71 f1         breq  .+92       ; 0x1624 <qtm_ptc_start_measurement_seq+0x6e>

10

    15c8:  24 30         cpi  r18, 0x04  ; 4

11

    15ca:  71 f1         breq  .+92       ; 0x1628 <qtm_ptc_start_measurement_seq+0x72>

12

    15cc:  80 93 98 3e   sts  0x3E98, r24  ; 0x803e98 <qtm_acquisition_control_working_set_ptr>

13

    15d0:  90 93 99 3e   sts  0x3E99, r25  ; 0x803e99 <qtm_acquisition_control_working_set_ptr+0x1>

14

    15d4:  60 93 63 3e   sts  0x3E63, r22  ; 0x803e63 <ptc_seq_measure_complete_pointer>

15

    15d8:  70 93 64 3e   sts  0x3E64, r23  ; 0x803e64 <ptc_seq_measure_complete_pointer+0x1>

16

    15dc:  20 ec         ldi  r18, 0xC0  ; 192

17

    15de:  20 93 18 06   sts  0x0618, r18  ; 0x800618 <gain_setting_int_cap+0x7f6e82>

18

    15e2:  dc 01         movw  r26, r24

19

    15e4:  ed 91         ld  r30, X+

20

    15e6:  fc 91         ld  r31, X

21

    15e8:  22 81         ldd  r18, Z+2  ; 0x02

22

    15ea:  20 34         cpi  r18, 0x40  ; 64

23

    15ec:  21 f4         brne  .+8        ; 0x15f6 <qtm_ptc_start_measurement_seq+0x40>

24

    15ee:  20 91 18 06   lds  r18, 0x0618  ; 0x800618 <gain_setting_int_cap+0x7f6e82>

25

    15f2:  20 62         ori  r18, 0x20  ; 32

26

    15f4:  05 c0         rjmp  .+10       ; 0x1600 <qtm_ptc_start_measurement_seq+0x4a>

27

    15f6:  20 38         cpi  r18, 0x80  ; 128

28

    15f8:  41 f4         brne  .+16       ; 0x160a <qtm_ptc_start_measurement_seq+0x54>

29

    15fa:  20 91 18 06   lds  r18, 0x0618  ; 0x800618 <gain_setting_int_cap+0x7f6e82>

30

    15fe:  28 62         ori  r18, 0x28  ; 40

31

    1600:  20 93 18 06   sts  0x0618, r18  ; 0x800618 <gain_setting_int_cap+0x7f6e82>

32

    1604:  10 92 1e 06   sts  0x061E, r1  ; 0x80061e <gain_setting_int_cap+0x7f6e88>

Hier wird z.B. auf Register 0x618 und 0x61e zugegriffen. Aus dem 
Handbuch lernen wir von Seite 31 dass ob 0x0600 der ADC/PTC bereich 
liegt. In der ADC-Dokumentation auf seite 367 sind aber nur register 
0x0600-0x60d und 0x610,0615 dokumentiert.

Ist zwar etwas mühselig, das Listingfile durchzugehen, aber nicht 
unmöglich der PTC-Zugriffe zu rekonstruieren.

Dieter R. schrieb:
> Weiter oben. Du kannst doch so gut mit Suchmaschinen umgehen.

Du schreibst nur Unsinn. Keine Ahnung, aber große Sprüche. Mach mal :-)

Hugo H. schrieb:

>
> Wieso antwortest Du auf Fragen an Tim
>
> Hast Du 2 Accounts?

Nein. Sorry, fühlte mich mit angesprochen. Tim hat seine Version aber 
auch schon gepostet. Noch weiter oben.

Tim  . schrieb:
> sigh was eigentlich immer das unproduktivie Debattieren hier?
>
> Ok, ich habe einfach mal eines der QTouch-Beispiele für den ATtiny817
> compiliert. Das Listingfile mitsamt Funktionsnamen ist direkt verfügbar.
>

> Hier wird z.B. auf Register 0x618 und 0x61e zugegriffen. Aus dem
> Handbuch lernen wir von Seite 31 dass ob 0x0600 der ADC/PTC bereich
> liegt. In der ADC-Dokumentation auf seite 367 sind aber nur register
> 0x0600-0x60d und 0x610,0615 dokumentiert.
>
> Ist zwar etwas mühselig, das Listingfile durchzugehen, aber nicht
> unmöglich der PTC-Zugriffe zu rekonstruieren.

Stimmt. Ich habe mir das auch angesehen, aber erstmal wieder aufgegeben. 
Die paar Labels scheinen nur Zufall zu sein, zugegriffen wird auf 
irgendwas ganz anderes mit meist enormem Offset, anscheinend ohne 
sinnvollen Bezug dazu.

Das Problem ist, dass man ja nicht nur die Register finden muss, sondern 
eine Idee entwickeln muss, welche Bits dadrin was bewirken. Wenn ich mir 
dann das Oszillogramm einerseits und die Beschreibung der 
Konfigurationsmöglichkeiten per API andererseits ansehe, dann ahne ich, 
dass das nicht ganz so einfach wird.

Gemeinsame Aktion, aufbauend auf dem, c-hater schon herausgefunden hat, 
wäre da sicher zielführenden.

Andre schrieb:
> habe ich was mit einem der neuen Attinys
> gemacht (die mit Debugging)

Kannst Du Dich nicht mehr an die genaue Bezeichnung erinnern?

Andre schrieb:
> Ich wollte dann noch einen ADC Kanal haben, war natürlich durch QTouch
> belegt.

Auch das hast Du vergessen - nämlich welcher das war?

Andre schrieb:
> Ich habe dann lange versucht, vom Programm aus den ADC quasi manuell
> anzuzapfen. Also eigene ISR dran hängen, den Multiplexer kurz umschalten
> und ein Ergebnis abzweigen, Code an vorhandene ISRs hängen, ..., alles
> was irgendwie zugänglich war.

Ja - und wie sah das genau aus (Code)?

Andre schrieb:
> Ergebnis: Geht nicht!

Klar - nix gemacht , nix geht! Einer von vielen 
"Nicht-Intelligent-Schwätzern" :-)

Dieter R. schrieb:
> Vor allem ist: "Redistribution ... in source ... forms ... permitted".

Ja, ist eine klassische 3-Klausel-BSD-Lizenz. Das darf man weitergeben 
und auch veröffentlichen.

Jörg W. schrieb:
> Ja, ist eine klassische 3-Klausel-BSD-Lizenz. Das darf man weitergeben
> und auch veröffentlichen.

Hast Du auch den Rest gelesen?

O.K. - macht mal. Wer nichts hat kann auch nichts weitergeben :-)

Dieter R. schrieb:
> Stimmt. Ich habe mir das auch angesehen, aber erstmal wieder aufgegeben.
> Die paar Labels scheinen nur Zufall zu sein, zugegriffen wird auf
> irgendwas ganz anderes mit meist enormem Offset, anscheinend ohne
> sinnvollen Bezug dazu.

Die Funktionslabels sind selbstbeschreibend. Hier ist eine Liste der 
verwendeten Register nebst Funktionen, in denen sie aufgerufen werden:

1

  ADC unit documented registers

2

3

  W   0x0600    qtm_ptc_start_measurement_seq, qtm_t81x_ptc_handler_eoc

4

  W   0x0601    qtm_measure_node

5

  W   0x0602    qtm_measure_node

6

  W   0x0603    qtm_ptc_start_measurement_seq

7

  W   0x0605    qtm_measure_node

8

  W   0x0608    qtm_measure_node

9

  W   0x060B    qtm_ptc_start_measurement_seq

10

  W   0x060A    qtm_ptc_start_measurement_seq

11

  R   0x0610    qtm_t81x_ptc_handler_eoc

12

  R   0x0611    qtm_t81x_ptc_handler_eoc

13

14

  Undocumented PTC registers

15

16

R/W   0x0618    qtm_measure_node, qtm_ptc_start_measurement_seq

17

  W   0x0619    qtm_measure_node

18

  W   0x061A    qtm_measure_node

19

  W   0x061B    qtm_measure_node

20

  W   0x061C    qtm_measure_node

21

  W   0x061E    qtm_ptc_start_measurement_seq 

22

23

R/W   0x0622    qtm_ptc_init_acquisition_module

24

  W   0x0626    qtm_measure_node

25

  W   0x062A    qtm_measure_node

Weiter mache ich jetzt aber nicht, da ich anscheinend keinen Controller 
mit moderner QTouch Hardware habe. Mit dem Debugger wird man schneller 
weiter kommen.

Hugo H. schrieb:
> Jörg W. schrieb:
>> Ja, ist eine klassische 3-Klausel-BSD-Lizenz. Das darf man weitergeben
>> und auch veröffentlichen.
>
> Hast Du auch den Rest gelesen?

Ich weiß nicht, was „der Rest“ für dich ist.

Das, was du da gezeigt hast, ist eine 3-Klausel-BSD-Lizenz. Auch die 
Gewährleistungsausschluss-Klausel danach ist völliger Standard.

Da brauchst du die Leute nicht anzupflaumen dafür, unter dieser Klausel 
ist im Internet massenhaft Opensource-Software veröffentlicht worden, 
insbesondere natürlich der Sourcecode vom BSD-Unix-Derivat selbst. Daher 
der Name der Lizenz. (Ursprünglich hatte sie 4 Klauseln, wobei die 
dritte Klausel später gestrichen worden ist, da insbesondere die 
GPL-Fraktion sie als unvereinbar mit der GPL ansieht und daher BSD-Code 
bei sich lange Zeit abgelehnt hatte.)

Wenn Atmicrochip später den Code unter restriktiveren Bedingungen 
verbreitet hat, können sie das natürlich tun (sie sind der 
Rechteinhaber), aber natürlich nicht rückwirkend für Code, den sie mit 
BSD-Lizenz einstmals weitergegeben haben.

Dieter R. schrieb:
> Und nützt offenbar nichts für die aktuelle Betrachtung

Das ist der Punkt mit diesem alten Code.

Tim  . schrieb:

> Weiter mache ich jetzt aber nicht, da ich anscheinend keinen Controller
> mit moderner QTouch Hardware habe. Mit dem Debugger wird man schneller
> weiter kommen.

https://www.microchip.com/en-us/development-tool/ATTINY817-XMINI

Ab € 10,58. Und im Gegensatz zu den Chips ab Lager lieferbar!

Jörg W. schrieb:
> Wenn Atmicrochip später den Code unter restriktiveren Bedingungen
> verbreitet hat, können sie das natürlich tun (sie sind der
> Rechteinhaber), aber natürlich nicht rückwirkend für Code, den sie mit
> BSD-Lizenz einstmals weitergegeben haben.

Auch das aktuelle Qtouch kommt mit der 3-clause BSD license.

Dieter R. schrieb:
> Ab € 10,58. Und im Gegensatz zu den Chips ab Lager lieferbar!

In der Tat :) Allerdings scheinst Du schon ein Board vorliegen zu haben. 
So schwer ist es nicht, einfach durchzusteppen und zu schauen was in 
welche Register geschrieben wird. Der PTC wird nur an wenigen Stellen 
angesprochen. Das Ergebnis liegt im ADC result-register.

Jörg W. schrieb:
> Das, was du da gezeigt hast, ist eine 3-Klausel-BSD-Lizenz. Auch die
> Gewährleistungsausschluss-Klausel danach ist völliger Standard.

O.K. - dann kann sich ja wer mag auf Deine Rechtskenntnis berufen. Ich 
bin (GsD) kein Rechtsanwalt und daher eher vorsichtig.

Tim  . schrieb:

> So schwer ist es nicht, einfach durchzusteppen und zu schauen was in
> welche Register geschrieben wird. Der PTC wird nur an wenigen Stellen
> angesprochen. Das Ergebnis liegt im ADC result-register.

Ich befürchte, das wird komplexer. Da laufen auch noch die Mechanismen 
der Burst-Frequenz-Modulation und der Kapazitäts-Kompensation. Und 
vermutlich noch ein paar andere. Wahrscheinlich braucht man das nicht 
alles, aber zum Teil. Und an der Stelle wird es schwierig, man muss 
nämlich begreifen, welche Teile man braucht.

Ich versuche erstmal was anderes, nämlich den zweifachen 
Charge-Transfer, einmal vom Touchbutton zum Sample-Kondensator und 
einmal andersrum zu Fuß nachzubauen. Ganz geht das aber nicht, weil man 
den Sample-Kondensator mit der "normalen" Mux-Hardware nicht auf Vcc 
aufladen kann.

Hugo H. schrieb:

> O.K. - dann kann sich ja wer mag auf Deine Rechtskenntnis berufen. Ich
> bin (GsD) kein Rechtsanwalt und daher eher vorsichtig.

Man muss ja auch nicht für jede Zeile Text Rechtsanwalt sein.

https://opensource.org/licenses/BSD-3-Clause

Jörg W. schrieb:
> Hugo H. schrieb:
>
>> O.K. - dann kann sich ja wer mag auf Deine Rechtskenntnis berufen. Ich
>> bin (GsD) kein Rechtsanwalt und daher eher vorsichtig.
>
> Man muss ja auch nicht für jede Zeile Text Rechtsanwalt sein.
>

Lass ihn. Er ist vorsichtig. Er benutzt keine Libraries, könnte ja 
Fallstricke in der Lizenz geben, und er sieht sich auch nicht Code an, 
den andere gepostet haben, sicher ist sicher.

Dieter R. schrieb:
> Lass ihn. Er ist vorsichtig. Er benutzt keine Libraries, könnte ja
> Fallstricke in der Lizenz geben, und er sieht sich auch nicht Code an,
> den andere gepostet haben, sicher ist sicher.

Warum sollte ich mir Code anschauen, der mir nichts bringt? Ich versuche 
auch nicht Wasser in einem Sieb nach Hause zu tragen.

Dieter R. schrieb:
> Ich befürchte, das wird komplexer. Da laufen auch noch die Mechanismen
> der Burst-Frequenz-Modulation und der Kapazitäts-Kompensation. Und
> vermutlich noch ein paar andere. Wahrscheinlich braucht man das nicht
> alles, aber zum Teil. Und an der Stelle wird es schwierig, man muss
> nämlich begreifen, welche Teile man braucht.

Also weisst Du, so kompliziert ist das alles nicht. Der QTouch 
Konfigurator erklärt alle Optionen und die bekommt man schon zugeordnet. 
Hast Du Angst vor der BSD3 Lizenz?

Btw, Ghidra kann auch AVR...

Anscheinend sind in diesem Thread aber alle nur an sinnlosen 
Metadiskussionen interessiert, wie man an den Bewertungen sieht. Ich 
klinke mich dann mal aus.

Hier sind auch noch ein paar Infos.
https://github.com/jgilbert20/Libre_PTC

> Ich versuche erstmal was anderes, nämlich den zweifachen
> Charge-Transfer, einmal vom Touchbutton zum Sample-Kondensator und
> einmal andersrum zu Fuß nachzubauen. Ganz geht das aber nicht, weil man
> den Sample-Kondensator mit der "normalen" Mux-Hardware nicht auf Vcc
> aufladen kann.

Natürlich geht das. Du könntest einen I/O PIN als Ausgang konfigurieren 
und dann den ADC über den Multiplexer mit diesem verbinden.

Übrigens ist das alles in der TinyTouchlib implementiert:
https://github.com/cpldcpu/TinyTouchLib/blob/7eb7866e6f166f9c9668dcffd517c061258f035c/TinyTouchLib.c#L79

Tim  . schrieb:

> Also weisst Du, so kompliziert ist das alles nicht. Der QTouch
> Konfigurator erklärt alle Optionen und die bekommt man schon zugeordnet.

Dass der QTouch-Konfigurator funktioniert, steht außer Frage. MEIN 
Interesse war,

1. eine Lösung zu finden, die bedeutend (!) weniger Speicher belegt als 
der damit generierte Code und nicht schlechter (?) funktioniert

sowie

2. wenn möglich (also bisher nicht), die QTouch-Hardware zu verstehen 
und im eigenen Code zu verwenden.

> Hier sind auch noch ein paar Infos.
> https://github.com/jgilbert20/Libre_PTC

Das ist keine Lösung, sondern illustiert allenfalls das Problem. Ein 
paar unverstanden zusammengehauene Codeschnipsel, die laut 
dokumentierter Issues nicht mal funktionieren.

>> ... Ganz geht das aber nicht, weil man
>> den Sample-Kondensator mit der "normalen" Mux-Hardware nicht auf Vcc
>> aufladen kann.
>
> Natürlich geht das. Du könntest einen I/O PIN als Ausgang konfigurieren
> und dann den ADC über den Multiplexer mit diesem verbinden.

Da hatte ich in der Tat ein Brett vor dem Kopf. Natürlich geht das, und 
man braucht nicht mal einen extra Pin dafür. Danke für den Hinweis.

> Übrigens ist das alles in der TinyTouchlib implementiert:

Stimmt, nochmals Danke für den Hinweis. Dass du in beiden Richtungen 
Charge Transfer machst, hatte ich beim ersten Durchlesen übersehen. Mir 
war da dieser Ansatz überhaupt noch nicht bewusst. Die Sinnhaftigkeit 
erschließt sich mir allerdings bisher nicht. Ich vermute stark, dass es 
die Störanfälligkeit verringert, aber die physikalisch-technische 
Erklärung dafür fehlt mir. Für Erklärungen oder auch nur hilfreiche 
Spekulationen wäre ich dankbar (!!!).

Aber:
  tmp=0;
  for (i=0; i<16; i++) {
    tmp+=tinytouch_adc();  // average 16 samples
    _delay_us(100);
  }

Genau sowas möchte ich vermeiden, nicht 1,6 ms auf eine Taste warten. 
Vermutlich müsste man sogar noch länger warten, falls Netzeinstreuungen 
eine Rolle spielen. Bei QTouch hilft dagegen (und gegen andere 
Störeffekte) die Shield-Elektrode, für eine eigene Lösung fehlt mir noch 
ein Ansatz. Es sollte nicht schwer sein, das Ganze in eine ISR 
auszulagern. Das war von vornherein MEIN Ansatz. Auch bei 
Atmel/Microchip ist das zumindest in der aktuellen Version NICHT gut 
gelöst, dauert aber jedenfalls keine 1,6 ms.

Nachtrag: grundsätzlich würde ich solche Sachen in einem regelmäßigen 
Zeitraster im Hintergrund laufen lassen und nicht hart einen Mittelwert 
über n Messungen zu einem zufälligen Abfragezeitpunkt bilden, sondern 
einen gleitenden Mittelwert über die regelmäßigen Abfragen. 
Atmel/Microchip macht das theoretisch so ähnlich, aber praktisch in 
grausamer Weise realisiert: Mittelwert über Burst, und diese Bursts 
müssen vom Anwenderprogramm zu Fuß (!) regelmäßig aufgerufen werden, 
sonst funktioniert es nicht. Auf so eine Lösung muss man erst mal 
kommen, und warum es sonst nicht funktioniert, begreife ich auch nicht.

Dieter R. schrieb:
<...>

Wenn Du jegliche Hilfestellungen nur kritisierst und nicht einmal selber 
die Arbeit investieren willst Dir Qtouch im Debugger anzuschauen oder 
gar die Dokumentation zhu lesen, dann solltest Du Dein Problem lieber im 
stillen Kämmerlein lösen.

Ich wollte diesem Thread eigentlich nichts mehr hinzufügen, muss aber 
leider doch anmerken, dass ich nachvollziehen kann, warum einige der 
Regulars hier so verbittert reagieren.

So, das wird aber jetzt wirklich meine letzte Antwort.

Dieter R. schrieb:
> Für Erklärungen oder auch nur hilfreiche
> Spekulationen wäre ich dankbar (!!!).

Stichworte: Chopping, Offset cancellation, linearization...

Tim  . schrieb:
> Dieter R. schrieb:
> <...>
>
> Wenn Du jegliche Hilfestellungen nur kritisierst

Ich hatte mich bedankt, fand deine Hilfe ausgesprochen nützlich und bin 
verwundert, dass du Dank als Kritik interpretierst. Verwechselst du mich 
da mit jemand anderem?

> Stichworte: Chopping, Offset cancellation, linearization...

Kann sein, muss eher nicht. Wenn das eine Rolle spielen würde, wären 
auch die normalen unipolaren A/D-Wandlungen in gleicher Weise 
fehlerbehaftet. Sind sie aber nicht. Folglich wird die physikalische 
Erklärung wohl wo anders zu suchen sein. Btw., ich bin Physiker und 
schreibe sowas nicht grundlos. Ich weiß aber auch, dass ich von vielen 
Dingen nichts weiß. Da frage ich dann nach Erklärungen.

Falls es noch jemanden interessiert, also wohl eher nicht, hier das 
Ergebnis mit ATtiny817, Messung umgesetzt nach dem Konzept von Tim, aber 
in ISR mit rolling average.

Der zeitkritische Teil der ISR dauert gut 50 us, kann man vielleicht 
noch ein bisschen optimieren. Das Ergebnis ist (erwartungsgemäß) immer 
noch nicht so wie bei Original QTouch. Mit PCB alleine ist die 
Empfindlichkeit und Stabilität sehr gut. 1 mm Acrylglas darüber gehen so 
ohne weiteres nicht, aber vermutlich kann man die Empfindlichkeit noch 
erhöhen.

Dieter R. schrieb:
> 1 mm Acrylglas darüber gehen so
> ohne weiteres nicht

Also ich kann nicht klagen, mein obiges C-Programm funktioniert 
einwandfrei durch ne Platine hindurch (1,5mm). Die Sensorfläche ist 
8*8mm².
Die Schaltschwelle habe ich auf unbetätigt + 10 festgelegt. Kleine 
Störungen und Doppelbetätigungen filtert die nachgeschaltete Entprellung 
zuverlässig heraus.
Weitere Tasten oder ADC-Messungen kann man einfach in den ADC-Interrupt 
mit einfügen.
Der Interrupt ist unkritisch. Falls andere Interrupts schnell reagieren 
müssen, kann man ihn als ISR_NOBLOCK definieren.
Ich wüßte jetzt also keinerlei Grund, warum ich die Atmel-Lib nehmen 
sollte.

Peter D. schrieb:

> Also ich kann nicht klagen, mein obiges C-Programm funktioniert
> einwandfrei durch ne Platine hindurch (1,5mm).

Sag ich ja. Bei dem Demo-Board liegen die Sensorflächen zwar nicht auf 
der Board-Unterseite, aber auch nicht oben, sondern irgendwo mittendrin. 
Das Signal bei der Differenzmessung ist 160 bis 200, Schaltschwelle habe 
ich auf 50 bis 60 gesetzt.

Nochmal 1 mm Acryl obendrauf geht aber so nicht, da muss man weiter dran 
drehen. Mit QTouch geht auch noch 3 bis 5 mm Acryl.

Dieter R. schrieb:
> Mit QTouch geht auch noch 3 bis 5 mm Acryl.

Hast Du denn besondere Anforderungen bezüglich Schlagfestigkeit?
Wie gesagt, für meine Anforderungen reicht mein Beispiel völlig. Daß man 
Seiteneffekte minimieren kann und weiterhin den ADC benutzen, ist ein 
großer Vorteil gegenüber dem PTC.

Die Sensorfläche kann man ja auf der Oberseite plazieren und mit einer 
Bottom-LED durch den Via hindurch beleuchten. Dann sind 1mm Acryl kein 
Problem.

Peter D. schrieb:

> Hast Du denn besondere Anforderungen ...

1. Bei einem speziellen Projekt, ja, aber das ist eine Designfrage, 
keine technische. QTouch funktioniert da ja, also zunächst kein Problem.

2. Ist es eine grundsätzliche Frage. Wenn man etwas anderes macht als 
QTouch nach Atmel-Rezept, also die von Atmel Start generierte 
Konfiguration mit der Atmel-Library, dann sollte es für allgemeine 
Verwendbarkeit möglichst viele Vorteile und möglichst wenige Nachteile 
bieten. Nach aktuellem Stand sind die

Vorteile: kleinerer Code, ADC ist nicht blockiert

Nachteile: weniger empfindlich und natürlich all der Schnickschnack von 
Atmel nicht so ohne weiteres dabei, Slider, Wheels, AKS, Driven Shield, 
hab ich noch was vergessen? Gestures?

Kleines Highlight, EINES der speziellen Register ist hier offiziell 
beschrieben:

https://microchip.wikidot.com/touch:guide-to-interpret-cc-calibration-value

Wir lernen daraus, dass es ein 16-Bit CC-Register gibt. Zumindest dessen 
beschriebene Bitzuordnung ist so, dass ich mir nicht zutrauen würde, 
dessen Funktion mit Debugging alleine zu entschlüsseln. Warum das 
Register hier beschrieben wird, ist mir auch nicht so recht klar, das 
scheint wohl eher ein Irrläufer zu sein. Es gibt dazu auch eine get- und 
eine update-Funktion im API. Erstere macht nichts anderes als in der 
Developer Help beschrieben, wofür man die Letztere brauchen könnte, 
bleibt unklar - wie so vieles.

Dies ist auch sehr informativ, zwar für sam geschrieben, trotzdem.

Chris S. schrieb:
> Dies ist auch sehr informativ, zwar für sam geschrieben, trotzdem.

Faszinierend und verwirrend umfangreich. Anscheinend ist das die 
Hardware-Dokumentation zur zugehörigen Linux-Software. Hast du auch 
einen Link zu dieser (vermutlich umfangreichen) Software? Allerdings 
befürchte ich, dass mir die Zeit und das Wissen fehlen werden, mich da 
durchzuarbeiten und eventuelle Rückschlüsse für die kleineren 
Prozessoren zu ziehen - aber man kann sich ja mal vornehmen, es zu 
versuchen.