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.
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.
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.
>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
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.
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.
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.
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.
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.
Angehängte Dateien:
-
PICT0607.JPG
380 KB
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 :-(
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...
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
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.
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.
Angehängte Dateien:
-
ATtiny817XP-Ttest-01.jpg
150 KB
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).
:
Bearbeitet durch User
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.
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.
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.
Angehängte Dateien:
-
qtouch.PNG
150 KB
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
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
PTC_DB.png
4,4 KB
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.
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
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.
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.
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
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.
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
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
|
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.
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.
Angehängte Dateien:
-
QTouch_4_3.png
37 KB
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
Angehängte Dateien:
-
QT-Ttest.jpg
140 KB -
QT-cycle.png
53 KB -
QT-pulse_chain.png
55 KB -
QT-detail.png
54 KB -
touch-cycle.png
48 KB -
touch-pulse.png
50 KB
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
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.
:
Bearbeitet durch User
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...
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. * ...
:
Bearbeitet durch User
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.
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.
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?
:
Bearbeitet durch User
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.
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.
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.
Angehängte Dateien:
-
qtouch4.3.PNG
81 KB
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
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.
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.
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.
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 :-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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.
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
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.
Angehängte Dateien:
-
ATtiny817XP-Ttest-022.jpg
160 KB -
touch-022-pulse_chain.png
140 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.