Doppelpieps erzeugen ?

Lightning schrieb:
> Wie realisiere ich das am besten
Ich weiß nicht, welche Kenntnisse du hast, aber ich würde einen 
ATtiny9 verwenden und ein paar Zeilen Software schreiben...

Man kann auch einen Piezo Buzzer ( anstatt Piezo Lautsprecher ) nehmen.
Der piept schon, wenn man Betriebsspannung anlegt.
So muss man sich nur noch um den Doppelimpuls kümmern.

Lothar M. schrieb:
> Lightning schrieb:
>> Wie realisiere ich das am besten
> Ich weiß nicht, welche Kenntnisse du hast, aber ich würde einen
> ATtiny9 verwenden und ein paar Zeilen Software schreiben...

Grad mal Farnell geguggt:
Tiny9 (0,67€) ist eine gute Wahl, sogar billiger als der Tiny10 
(0,845€), der meine Standardwahl gewesen wäre.
Überraschend, weil ich beim Tiny10 eine höhere Verbreitung und damit bei 
kleinen Stückzahlen einen niedrigeren Preis erwartet hätte.

Aber richtig Geld sparen kann man beim Einsatz eines PIC10F200 - nur 
0,483€.

Das wäre mal wieder ein Spaßprojekt, so wie dieses hier:
http://www.harerod.de/applications_ger.html#TQ10_melody

Geht aber auch problemlos im fliegenden Aufbau - siehe Bild.

npn schrieb:
> Marcus H. schrieb:
> War der Hamster nach dem Abkauen der Platine wenigstens satt? :-)))
> Oder hat er anschließend eine neue Herausforderung verlangt (FR4)?

Das war meine Meise. Die ist schon ein näschertes Vieh - da legt man 
extra Hühnerfutter hin - und was wird angefressen - genau, die 
Platine...

pieps schrieb:

>>so einen Doppelpieps erzeugen, wie bei der FB vom Auto
>
> so wirds kompliziert. Der Ton ist komplex aufgebaut, ein MP3-File ist da
> die bessere Wahl.

Hmm, solche Tonerzeuger waren doch massenhaft in alten,
amerikanischen Autos verbaut. Ichglaube nicht, das die
mit MP3-Files gearbeitet haben. Gabs dafür vielleicht
sogar ein Spezial-IC?

Sowas hier?

car-sound-original.mp3:
wie es vermutlich klingen sollte.

car-sound-square.mp3
Rechtecksignale mit verschiedenen Frequenzen hintereinander abgespielt:

2200 Hz für 5ms
2000 Hz für 5ms
 950 Hz für 30ms
1000 Hz für 7ms
1125 Hz für 7ms
1250 Hz für 7ms

car-sound-square-filtered.mp3
Gleiches Signal, aber durch einen Tiefpassfilter geschickt 
(Grenzfrequenz 1KHz)

@Joe F.. klingt ja echt gut. Ich hätte es auch mit verschiedenen 
Frequenzen und nem Filter gemacht, aber wie kamst du auf diese Sequenz? 
also wie lange und welche Frequenz? Ausprobieren? Mit einem Programm 
analysiert?

Das "Original" stammt von Youtube, und dann mit Audacity ein paar 
Eckpunkte analysiert (timing, frequenz).
So richtig mega-super-duper ist es noch nicht, aber müsste in dieser Art 
machbar sein.
Mit ein paar NE555 geht das natürlich nicht. Ein Mikrocontroller sollte 
da schon her...

Joe F. schrieb:
> Mit ein paar NE555 geht das natürlich nicht. Ein Mikrocontroller sollte
> da schon her...

Eine zünftige Röhrenendstufe und ein paar wertige Lautsprecher müssen an 
den Tiny9 noch ran, damit die volle Bandbreite sauber wiedergegeben 
wird.

Scherz beiseite - schau Dir den Frequenzgang von Deinen Piezoquäkern an.
Ich hab mir die Signale mal angehört - selbst das gefilterte Signal hat 
deutliche Anteile im ganzen hörbaren Spektrum.

Marcus H. schrieb:
> selbst das gefilterte Signal hat
> deutliche Anteile im ganzen hörbaren Spektrum.

Es wäre schlecht, wenn es nicht so wäre... ;-)

Joe F. schrieb:
> Marcus H. schrieb:
>> selbst das gefilterte Signal hat
>> deutliche Anteile im ganzen hörbaren Spektrum.
>
> Es wäre schlecht, wenn es nicht so wäre... ;-)

Hab mich auch gewundert. :(

Joe F. schrieb:

>> selbst das gefilterte Signal hat
>> deutliche Anteile im ganzen hörbaren Spektrum.
>
> Es wäre schlecht, wenn es nicht so wäre... ;-)

Vermutlich gibt es sogar noch Anteile ausserhalb des hörbaren Bereiches.
:-))

Hat mit dem Thema "(einfacher) Doppelpieps" ja nicht mehr viel zu tun,
trotzdem, weil es mir gerade ein wenig Spaß macht:

1. Ton (alles Rechteck):
- Sweep von 3000 Hz nach 2000 Hz in 30ms
- Dauerton 1000 Hz für 30ms
- Sweep von 1000 Hz nach 1200 Hz in 30ms

2. Ton:
gleiches Timing, aber alle Frequenzen 6% höher

Filter:
TP @2 KHz (-3dB/oct)
HP @1 KHz (-3dB/oct)

:-)

Joe F. schrieb:
> Filter:
> TP @2 KHz (-3dB/oct)
> HP @1 KHz (-3dB/oct)

Ah - das erklärt, warum das Audiosignal noch so breitbandig ist.
Ich hatte gestern eigentlich schon fragen wollen, wie steil Deine Filter 
sind.

Ich habe mir die Deine Muster bisher nur auf zwei Bose-Quäkern angehört 
(Companion 2 Series III). Die haben vermutlich einen anderen 
Frequenzgang als der Piezo vom TO.

Bei meinem Melodiemodul-Demonstrator gehe ich auch mit Rechteck über TP1 
auf Piezos wie man sie aus Melodiekarten kennt.

Joe F. schrieb:
> Hat mit dem Thema "(einfacher) Doppelpieps" ja nicht mehr viel zu tun,
> trotzdem, weil es mir gerade ein wenig Spaß macht:

Weil es mir auch gerade ein wenig Spaß macht, habe ich mir einen kleinen 
Controller sowie einen kleinen Piezoschallgeber hergenommen und grob 
entsprechend dem nachfolgenden Timing programmiert.  Programm und eine 
Handyaufnahme vom Output im Anhang, Details weiter unten.

>
> 1. Ton (alles Rechteck):
> - Sweep von 3000 Hz nach 2000 Hz in 30ms
> - Dauerton 1000 Hz für 30ms
> - Sweep von 1000 Hz nach 1200 Hz in 30ms
>
> 2. Ton:
> gleiches Timing, aber alle Frequenzen 6% höher
>
> Filter:
> TP @2 KHz (-3dB/oct)
> HP @1 KHz (-3dB/oct)
>
> :-)


Das Programm nutzt den NCO (Numerically Controlled Oscillator) des 
10F320 und besteht i.W. aus Warteschleifen, zwischen denen der Increment 
Value des NCO-Akkumulators jeweils neu gesetzt wird. Viel plumper geht's 
nicht. :-) Immerhin sind auf diese Weise von den 256 Worten Program 
Memory nur ungefähr zwei Drittel belegt, also noch Luft für die 
Behandlung z.B. einer Taste.

Mit dem 10LF320 und nur 3.3 V ist das nicht sonderlich laut. Da man 
ggfs. für mehr "Wumms" noch einen Transistor bemühen wird, habe ich mir 
keine Mühe bzgl. einer evtl. Filterung gemacht.

Der 10(L)F320 kostet derzeit bei Reichelt 0,74 €,
der EKULIT RMP-14P/HT 0,67 €. Weitere Bauteile sind nicht nötig.

Alternativ ist das Programm auch hier 
https://bitbucket.org/ws01/doppelpieps zu finden.

jefälltma

Wolfgang S. schrieb:
> Mit dem 10LF320

Hallo Wolfgang,
freut mich, dass Du was für die Artenvielfalt tust. :)

Dem Teil jetzt noch einen Stromsparmodus verpasst und es braucht nochmal 
500nA weniger Standbystrom als meine Tiny10 Assemblerlösung. neid

Wenn's längere Melodien werden sollen, dann böte sich Assembler an - der 
Mehraufwand zum C-Code wäre minimal, aber es wäre effektiv mehr 
Programmspeicher frei.

Schönen Sonntag,
 marcus

Marcus H. schrieb:
> Wolfgang S. schrieb:
>> Mit dem 10LF320
>
> Hallo Wolfgang,
Hallo Marcus.

> freut mich, dass Du was für die Artenvielfalt tust. :)

Das ist nicht primär meine Absicht, sondern dem Umstand geschuldet, daß 
ich mich mit ein paar von denen einigermaßen auskenne und für eine 
Freizeitbeschäftigung keinen Nutzen darin sehe, Variationen desselben 
Themas zu studieren.


>
> Dem Teil jetzt noch einen Stromsparmodus verpasst und es braucht nochmal
> 500nA weniger Standbystrom als meine Tiny10 Assemblerlösung. *neid*

Kann man tun, wenn man es braucht. Aktuell fällt mir keine praktische 
Verwendung ein, auch der Threaderöffner hat ja nicht verraten, welchem 
Zweck das dienen sollte.

>
> Wenn's längere Melodien werden sollen, dann böte sich Assembler an - der
> Mehraufwand zum C-Code wäre minimal, aber es wäre effektiv mehr
> Programmspeicher frei.

Ein gefährliches Thema, weil das schnell in die bekannten, ziemlich 
unergiebigen Streitereien mündet.

Was mich betrifft, ich habe in meinen ersten Berufsjahren genügend 
Assemblerprogramme geschrieben und auch viel Zeit darauf verwendet (oder 
damit verschwendet), Kollegen aus Löchern herauszuhelfen, die sie sich 
per Assembler geschaufelt hatten, als daß ich dem Thema noch viel 
abgewinnen könnte.  Die Effektivität des Programmierens in Assembler 
wurde auch vor dreissig Jahren häufig überschätzt.  Was allerdings nicht 
heißt, daß das blinde Vertrauen in "die Hochsprache wird's schon 
richten" und die entsprechende Propaganda die richtige Reaktion darauf 
ist. Insbesondere dann nicht, wenn mit Hochsprache C gemeint ist.  Ich 
war versucht, dem einen oder anderen, der an den Schlammschlachten in 
anderen Threads teilgenommen hat, mal einen Blick in 
http://blog.regehr.org/archives/1180 und auch die dort verlinkten 
Artikel zu empfehlen.  Ich hab's mir verkniffen.

Im konkreten Fall, angenommen, ich wollte tatsächlich komplexere 
Tonfolgen produzieren als diesen simplen Doppelpfiff, wüsste ich eine 
ganze Reihe von Ansätzen, die ich zunächst verfolgen bzw. empfehlen 
würde, bevor ich das ganze Programm in Maschinensprache resp. Assembler 
schriebe.

Zunächst mal gibt es noch einige Luft dadurch, daß das als bloßer Proof 
of Concept in fünf Minuten so runtergeschrieben war. Ich vermute, daß 
sich durch Verwenden eines Timers statt der mehrfachen Warteschleifen 
das Programm deutlich eindampfen ließe.

Dann stellt sich natürlich die betriebswirtschaftliche Frage: lohnt sich 
das überhaupt?  Welche Stückzahlen sind nötig, den Mehraufwand für die 
Programmierung wieder reinzuholen?

Für ein Hobbyprojekt bzw. ein Unikat wäre es vmtl. sinnvoller, einen der 
etwas größeren Prozessoren zu verwenden, die auch einen NCO haben, z.B. 
den 12F1501.   Den 10LF320 verwende ich hauptsächlich deswegen, weil 
ich, als die mal sehr billig von Reichelt angeboten wurden, eine 
Handvolld davon gekauft habe.  Und natürlich aus sportlichen Gründen. 
:-)

Wenn es um ein Produkt geht, wäre erst mal abzuchecken, ob nicht die 
teuren, nicht gekrippelten XC8-Versionen besseren Code produzieren.

Noch ein Aspekt, der mich abschreckt, außer in Notfällen noch umfänglich 
Assembler einzusetzen (Berühungsängste habe ich da wie gesagt nicht), 
besteht darin, daß ich durch das, was ich vor zig Jahren als Assembler 
verwenden durfte, ein wenig verwöhnt bin.  Die aktuellen Makroassembler 
erlauben es nicht, Assemblerprogramme in einer Weise zu formulieren, wie 
ich es mir wünschte.  Und die Zukunft liegt nicht in besseren 
Assemblern, sondern in besseren Codegeneratoren und geeigneteren 
Programmiersprachen. Es lohnt sich m.E., die Entwicklung von Rust für 
den Embedded-Bereich zu verfolgen.     Für Freizeitbeschäftigungen wie 
meine ist das aber eher theoretisch.

>
> Schönen Sonntag,
>  marcus

Dito.

Hi Wolfgang,
Dein Beitrag liest sich interessant.
Ich bin zwar nicht 100% auf Deiner Linie, aber das wäre ja auch 
langweilig.

Ich bekomme glücklicherweise immer wieder Projekte, bei denen die 
Randbedingungen Freiraum zum tunen geben. Erst letzte Woche habe ich 
wieder eine Servosteuerung auf Tiny10 in Maschinensprache rausgeschoben.
Ist immer wieder eine schöne Abwechslung zu den STM32.

Danke für das Stichwort "Rust". Das hat zwar verhalten geklingelt, aber 
ich musste nachschauen. Da werde ich mal nachhaken:
http://www.embedded.com/design/programming-languages-and-tools/4428704/Alternatives-to-C-C--for-system-programming-in-a-distributed-multicore-world

Und die letzte wichtige Erkenntnis:
PIC10F200 und ATtiny10 sind im SOT23-6 pinkompatibel.

Cheerio,
 marcus

@Wolfgang S.
Zwar sehr offtopic, aber kann's mir nicht verkneifen: es tut echt gut, 
wenn man auf solche Beitraege wie Deine stösst, die in einem leicht 
leserlichen, grammatikalisch und orthografisch fehlerfreiem Deutsch 
geschrieben wurden. Danke.

Marcus H. schrieb:
> Hi Wolfgang,
> Dein Beitrag liest sich interessant.
> Ich bin zwar nicht 100% auf Deiner Linie, aber das wäre ja auch
> langweilig.

Genau. :-)

>
> Ich bekomme glücklicherweise immer wieder Projekte, bei denen die
> Randbedingungen Freiraum zum tunen geben. Erst letzte Woche habe ich
> wieder eine Servosteuerung auf Tiny10 in Maschinensprache rausgeschoben.
> Ist immer wieder eine schöne Abwechslung zu den STM32.

Daß das Spaß macht und in Einzelfällen auch vernünftig ist, glaube ich 
gerne, wobei ich das "vernünftig" aus der Ferne natürlich nicht 
beurteilen kann.

>
> Danke für das Stichwort "Rust". Das hat zwar verhalten geklingelt, aber
> ich musste nachschauen. Da werde ich mal nachhaken:
> 
http://www.embedded.com/design/programming-languages-and-tools/4428704/Alternatives-to-C-C--for-system-programming-in-a-distributed-multicore-world

Das ist auch interessant, ich dachte aber eher an den Aspekt, daß Rust 
zumindest theoretisch auch runtimefree eingesetzt werden kann und 
insofern vielleicht doch irgendwann mal die Alternative zu Assembler 
entsteht, die mir vorschwebt.  Zukunftsmusik, ich weiß.

Hier

https://www.reddit.com/r/rust/comments/2web3t/is_rust_going_to_replace_cc_when_it_comes_to/

glaubt jemand nicht, daß Rust diese Rolle erfüllen kann. Ich meine, daß 
es noch zu früh ist, sich diesbezüglich eine abschließende Meinung zu 
bilden. Die Rust-Entwickler haben derzeit andere Probleme und es kommt 
m.E. auch auf die Zuarbeit aus der Embedded-Ecke an.  Wenn ich zwanzig 
Jahre jünger wäre ...

>
> Und die letzte wichtige Erkenntnis:
> PIC10F200 und ATtiny10 sind im SOT23-6 pinkompatibel.

Das ist sicherlich praktisch und auf jeden Fall vernünftig, vor allem 
bei so wenigen Pins.

Sooo,
im Anhang ein Schaltungsvorschlag für einen tastengesteuerten Quäker.

Die Platine ist mit 29mm x 24mm um einen CR2032 Knopfzellenhalter 
aufgebaut. Die CR2032 wird mit 220mAh angenommen.

Der Lautsprecher wird über optionale Filter im Gegentakt betrieben, um 
auch das letzte Milliwatt aus den Endstufen zu pressen.

Der SMD-Taster kann wahlweise auch durch einen Sensor ersetzt werden. 
Der R101 ermöglicht den Verzicht auf die eingebauten Pullups.

Im Einstiegsmodell werkelt ein PIC10F200 mit 1MIPS. Hier sind 
Standby-Ströme im Bereich von 1µA zu erreichen.

Für Poweruser steht eine Hochleistungsvariante mit ATtiny9 zur 
Verfügung. Dieser Bolide geht mit nominal 9,6MIPS ins Rennen. Bezahlt 
wird dies jedoch mit 50% Mehrkosten für die MCU (0,67€ statt 0,48€) und 
einem erhöhten Standby-Stromverbrauch von ca. 2µA.

Programmiert wird die Baugruppe über TagConnect TC2030NL kompatible 
Pads, so dass hier in der Großserienfertigung keine Zusatzkosten 
entstehen.

Für beide MCUs stehen zahlreiche freie Programmierwerkzeuge zur 
Verfügung.
Sei es Assembler für den sportlichen Enthusiasten, über C-Compiler für 
den routinierten Profi, bis zur Arduino-Sketch* für den ambitionierten 
Einsteiger.

Grüße,
 Marcus

* für Arduino-Sketch ist ein ATtiny10 erforderlich. Die 
Hardware-Zusatzkosten gegenüber ATtiny9 belaufen sich auf ca. 50%.