Forum: Mikrocontroller und Digitale Elektronik Was ist bzw. war Atmel QTouch?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jan (Gast)


Lesenswert?

Ich habe das im Handbuch immer übersprungen, da ich meine Libs gerne 
selber schreibe. Aber zu QTouch finde ich im Handbuch gar nichts. Ist 
das etwas streng geheimes in Hardware gegossenes, was man nur über die 
Lib freischalten kann, oder ist das Marekting-Gewäsch und es ist eine 
reine Software-Implementierung, die auch auf jedem anderen Controller 
laufen würde?

Im Endeffekt muss ich wissen, ob ich dieses QTouch-Zeug brauche, oder 
nicht.

von Chris (Gast)


Lesenswert?


von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Arbeiter (Gast)


Lesenswert?

Es gibt(gab) doch von Atmel auch den IC AT42QT1070. Der arbeitet doch 
nach diesem Prinzip und man kann wunderbare Kontaktlose Tasten damit 
aufbauen. Das ganze geht doch auch ohne teure Software und läuft sehr 
zuverlässig.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

>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

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Soul E. (Gast)


Lesenswert?

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.

von Jan (Gast)


Lesenswert?

Mich wundert nur, dass es dazu keine Hardware-Docs gibt. Den 
Schmitt-Trigger kann also nur eine Lib abschalten? Dann muss es doch 
geheime Register geben? Wenn die bekannt wären, bräuchte man ja keine 
closed source lib mehr.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> 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.

Sicher ist: was auch immer in dem ursprünglich gekauften Software-Zeug 
drinne war, ist größtenteils in die Hardware gewandert, insbesondere die 
eigentliche Funktionalität. Die heutige Lib stellt im Wesentlichen bloß 
noch Verwaltungsfunktionen bereit und konfiguriert die Hardware. Sie 
macht selber keinerlei Signalverarbeitung oder sowas in der Art.

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

Für Assemblerprogrammierer schon ;o)

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. Vieles ist naturgemäß in den entsprechenden 
Konstantendeklarationen des API wieder zu finden und man braucht's nur 
durch den Code bis zum SFIOR-Zugriff zu verfolgen. Damit offenbart sich 
nebenbei auch gleich die grundlegende Struktur des Registersatzes und 
der Zusammenhang zwischen den Verwaltungsstrukturen und der Hardware in 
weiten Teilen.

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.

von Ingo W. (uebrig) Benutzerseite


Angehängte Dateien:

Lesenswert?

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 :-(

von c-hater (Gast)


Lesenswert?

Ingo W. schrieb:

[...]

Viel ziemlich zeitkritisches Zeug. Kann man machen, muss man aber nicht, 
wenn man die QTouch-Hardware hat. Die kann das (etwas) besser, vor allem 
kann sie es aber auch, ohne die MCU mit irgendwelchem zeitkritischen 
Kram zu behelligen.

Insbesondere unterstützt sie auch Matrizen von Touch-Elementen direkt. 
Das ist ziemlich geil. Wenn man dann auch noch einen AVR128DA64 hat, 
geht da einiges, bis hin zu 529 Touch-Elementen. Bei der Menge wird dann 
sogar schon langsam das reine Abfragen der Ergebnisse der Hardware 
wieder eine Sache, die zeitkritisch sein könnte...

von Ingo W. (uebrig) Benutzerseite


Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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

von Max M. (Gast)


Lesenswert?

Dieter R. schrieb:
> würde auch
> gerne von der aufgeblasenen, fast 8 kByte großen Originalversion
> wegkommen.

Wenn man das Charge Transfer Verfahren verstanden hat ist das mit fast 
jeder MCU und ein paar Zeilen Code umzusetzen.
Einfach die Atmel Dokus lesen, da wird das super erklärt.
Aber dann hat man nur einen stark schwankenden ADC Wert aus dem man grob 
sehen kann ob gedrückt oder nicht.
Alle Tricks und Kniffe die Cap Flächen robuster gegen sich verändernde 
Umweltbedigungen zu machen (z.B. Touch Fläche hinter Duschfliese), 
Slider, Wheels etc. pp. muss man sich dann wieder selber zusammencoden.

von Dieter R. (drei)


Lesenswert?

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.

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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.

von Dieter R. (drei)


Angehängte Dateien:

Lesenswert?

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?

von Dieter R. (drei)


Lesenswert?

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

von Tim  . (cpldcpu)


Lesenswert?

> 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.

von Tim  . (cpldcpu)


Lesenswert?

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).

: Bearbeitet durch User
von Dieter R. (drei)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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?

von Dieter R. (drei)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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, das Wesentlich hate ich bereits geposted: Die Tatsache, das die 
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.
Die Lib parametriert diese Hardware, sorgt für den Abruf der Ergebnisse 
von der Hardware und verwaltet das ganze in der obersten Ebene in 
"Buttons" und "Sliders" und so'n Quatsch.

Für's RE ist sie nur insofern nützlich, als dass man den Aufruf etlicher 
API-Funktionen bis zum Register-Zugriff auf die Hardware verfolgen und 
somit wenigstens einen Teil der Registerbits auch funktional 
entschlüsseln kann.

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.

von Tim  . (cpldcpu)


Lesenswert?

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?

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

c-hater schrieb:
> die Hardwareregister nicht dokumentiert sind

Das klingt nach Märchenonkel und ist sehr unwahrscheinlich!

von Dieter R. (drei)


Lesenswert?

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.

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

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...

: Bearbeitet durch User
von Dieter R. (drei)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

: Bearbeitet durch User
von c-hater (Gast)


Angehängte Dateien:

Lesenswert?

Tim  . schrieb:

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

Genau das. Und das ist auch kein großes Geheimnis. Kann man sowohl im DB 
sehen als auch in den Asm-Includes aus dem Device-Pack. Ersteres gibt 
zu, dass es die Hardware gibt, letztere deklariert immerhin die 
Basisadresse der Sache.

Und das war's.

Screenshot ist für den konkreten Fall AVR128DAxxx. Man beachte hier die 
Absenz der sonst üblichen Registerbeschreibung.

von Tim  . (cpldcpu)


Lesenswert?

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

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

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

Du hast sowas von keine Ahnung, dass du nichtmal einschatzen kannst, wie 
ahnungslos du eigenlich bist.

von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?


von Dieter R. (drei)


Lesenswert?

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.

: Bearbeitet durch User
von Apollo M. (Firma: @home) (majortom)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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).

von Peter D. (peda)


Lesenswert?

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.

von chris (Gast)


Lesenswert?

Auch interessant, die verschiedenen Ansteumöglichkeiten sowie dass 
q-touch bei Matrix nicht über 4.5V funktioniert.

http://ww1.microchip.com/downloads/en/appnotes/atmel-42094-qtouch-schematic-and-layout-checklist_applicationnote_at02259.pdf

von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

Peter D. 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."

Das scheint aber bei den AVR128DA/B nicht so zu sein, zumindest fehlt 
dort dieser Satz.
Ich kann mir eigentlich kaum vorstellen, dass der PTC tatsächlich 
unterschiedlich arbeitet, aber es ist natürlich auch nicht völlig 
unmöglich.

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

von Dieter R. (drei)


Lesenswert?

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.

Beitrag #6979776 wurde vom Autor gelöscht.
von Hugo H. (hugo_hu)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Dieter R. (drei)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Hugo H. (hugo_hu)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Hugo H. schrieb:
> c-hater schrieb:

> 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.

Nene, das war genau andersrum. Zuerst gab es die reine Softwarelösung, 
dann gab es den PTC. Und dessen Ansteuerung wurde einfach in das Korsett 
der alten Lib gezwungen. Die Unterschiede waren aber wohl so groß, dass 
sie einfach eine neue Lib geschrieben haben, bei nur die oberste 
API-Ebene mit der alten identisch ist, die, in der auf der Ebene von 
"Buttons" usw. hantiert wird.

Das Putzige ist, dass es offensichtlich auch Unterschiede innerhalb der 
neuen Generation mit PTC gibt. Zwar nicht in der Lib, aber in der der 
Hardware.

Vielleicht aber auch nicht. Könnte einfach auch nur ein Fehler im DB 
sein, also entweder der bewußte Satz ist bei den Tinys zu viel oder 
wurde bei den AVR128D.... schlicht vergessen.

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

von Tim  . (cpldcpu)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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.
*
...

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

Tim  . schrieb:

> Ernsthaft?

Ja.

> Ich halte die ex-Atmel DB immer noch mit für die besten.

Waren sie auch. Bis MC sie "verbessert" hat. Ich habe schon lange 
aufgehört zu zählen, wieviele DB-Fehler dabei neu entstanden sind.

von Hugo H. (hugo_hu)


Lesenswert?

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).

von Hugo H. (hugo_hu)


Lesenswert?

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?

: Bearbeitet durch User
von Hugo H. (hugo_hu)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

Hugo H. schrieb:

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

Ähem... Was soll "anonymisierter Code" sein? Und außerdem: 
reassemblierten Code braucht man nicht veröffentlichen, denn das wäre 
dann wieder die ursprüngliche Lib, die keiner will. Wennschon, müsste 
man disassemblierten Code veröffentlichen.

Jeder, der sich mit sowas auskennt, weiß allerdings, dass das rohe 
Disassemblat selbst für gestandene Asm-Programmierer erstmal nicht 
besonders nützlich ist. Damit fängt die eigentliche Arbeit erst an.

von Tim  . (cpldcpu)


Lesenswert?

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

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

von Dieter R. (drei)


Lesenswert?

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.

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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?

von Hugo H. (hugo_hu)


Lesenswert?

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?

von Hugo H. (hugo_hu)


Lesenswert?

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

Ja - wie schon geschrieben.

von Hugo H. (hugo_hu)


Lesenswert?

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

Wo? Link?

von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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?

von Tim  . (cpldcpu)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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 :-)

von Dieter R. (drei)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Andre (Gast)


Lesenswert?

Für ein kleines LED Projekt habe ich was mit einem der neuen Attinys 
gemacht (die mit Debugging). 3 Touch Buttons, PWM, nichts großes.
Ich wollte dann noch einen ADC Kanal haben, war natürlich durch QTouch 
belegt.
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.
Ein paar Nebeneffekte auf QTouch hätte ich in Kauf genommen.

Ergebnis: Geht nicht!

Die QTouch Bibliothek schreibt bei der Initialisierung irgendwelche 
Werte in undokumentierte Register, die knapp hinter denen von der ADC 
Konfiguration liegen.
Im Debugger konnte man das nachvollziehen, aber natürlich nicht in deren 
fertigen binär Blob reinschauen.

Sobald QTouch initialisiert ist, stehen weder die Pins noch der ADC zur 
Verfügung. Ich konnte nicht einmal die Datenrichtung manuell setzen und 
high/low Pegel überschreiben. Auf dem Oszilloskop hatte ich auch den 
Eindruck, dass die da mit den I/O Zellen eine Art kapazitive Kopplung 
schalten können.
Leider habe ich das nicht weiter verfolgt, weil ich hauptsächlich den 
ADC Kanal haben wollte und QTouch super lief.
Aber als Einstiegspunkt für weitere Untersuchungen ist so ein moderner 
Attiny mit Debugger sicher gut geeignet.

von Hugo H. (hugo_hu)


Lesenswert?

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" :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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 :-)

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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!

von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von Hugo H. (hugo_hu)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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.

von Hugo H. (hugo_hu)


Lesenswert?

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.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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

: Bearbeitet durch User
von Asdf Q. (Gast)


Lesenswert?

Tim  . schrieb:
> 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.

QTouch 4 ist ein reines charge transfer-Verfahren. Das lief auf 
klassischen ATmega ohne jegliche Zusatz-HW, bzw eigentlich auf jedem 
Controller, der einen GPIO und einen (GPIO-fähigen) ADC-Kanal frei hat. 
Man durfte das Patent kostenlos nutzen, wenn im Design ein AT(X)mega 
verwendet wurde. Es musste aber nicht zwangsläufig auf diesem 
implementiert sein, er musste nur auf der gleichen Leiterplatte sitzen.

Das, was heute als QTouch verkauft wird nutzt spezielle Hardware und 
entspricht damit eher dem Ansatz der Cypress PSOC. Gleicher Name, aber 
ganz andere Technik.

von Dieter R. (drei)


Lesenswert?

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.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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...

von Dieter R. (drei)


Lesenswert?

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.

von Dieter R. (drei)


Angehängte Dateien:

Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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?

von Dieter R. (drei)


Lesenswert?

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.

von Chris S. (schris)


Angehängte Dateien:

Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.