beep-debugging

[Bauform B. (bauformb)]

Mahlzeit!

printf-debugging war gestern, beep-debugging regelt! Diese winzigen 
"Lautsprecher" für Platine haben zwar Resonanzstellen, aber doch einen 
Tonumfang wie (handliche) Musikinstrumente. Auch ein unmusikalischer 
Programmierer kann mehr als 3 Tonhöhen unterscheiden. Einen einzelnen 
Ton kann man praktisch überall ausgeben, z.B. im Interrupt, wo andere 
Debug-Ausgaben schlecht möglich sind.

Soweit so gut und in der Praxis bewährt. Bei einem Cortex-M0 kann man 
beep() keine Frequenz übergeben weil der keinen Divisionsbefehl hat. Na 
gut, übergibt man eben direkt den Wert den der Timer braucht, z.B. 4545 
für ein a'. Dafür braucht man aber Namen, ein paar Konstanten. Aber wie 
schreibt man das in C?

Gibt es genormte Namen für Töne? Also für Programmierer, nicht für 
Musiker. "C0" bis "H8" ist schlecht, weil manche Leute "A3" und andere 
"A4" für den Kammerton schreiben. Außerdem ist der Name zu kurz. Ich hab 
"note_C2" bis "note_h5" probiert, aber das sieht doof aus und so lang 
müssen die Namen auch wieder nicht sein. Wie beliebt ist eigentlich das 
'$' in C, also "$a1" als Tonname?

[Stefan F. (Gast)]

Wenn du schon einen Pin frei hast, um Töne auszugeben, kannst du da auch 
gleich Texte mit UART Protokoll ausgeben.

Ich kombiniere Debug Ausgaben gerne mit einer bedrahteten Power-LED, der 
kann man leicht einen Clip ans Bein hängen, um die Meldungen auszulesen.

[Harald A. (embedded)]

Du kannst einer Prozedur keine Frequenz übergeben, weil der verwendete 
Mikrocontroller keinen Divisionsbefehl kennt? Erkläre das bitte mal 
näher…

[Stefan F. (Gast)]

Was soll das denn werden? Sollen die Menschen nach dem Morsecode nun 
deinen Musik-Code auswendig lernen? Das macht doch keiner mehr, wir sind 
im 21. Jahrhundert!

Gebe die Meldungen einfach seriell aus. Jeder Techniker wird wohl 
imstande sein, einen USB-UART an zwei Pins (Gnd und TxD) anzuschließen. 
Wenn Pins Mangelware sind, kann man das mit einer Power-LED kombinieren. 
Man braucht dazu auch nicht zwingend einen UART, das ist ebenso per 
Bit-Banging mit wenigen Zeilen Code machbar.

Und wenn die Ausgabe für nicht-Techniker sein soll, dann nimm ein 
anständiges Display oder eine 7-Segment Anzeige. Codes wie "E12" bei der 
Waschmaschine kann jeder begreifen, der die Anleitung liest. Musik 
Dekodieren ist eine ganz andere Liga.

[omnna (Gast)]

ich würde mit den Midi-Codes arbeiten.
https://www.zem-college.de/midi/mc_taben.htm

[c-hater (Gast)]

Bauform B. schrieb:

> printf-debugging war gestern, beep-debugging regelt!

Glaub' ich nicht wirklich. Alle diese Debug-Arten haben ein gemeinsames 
Problem: sie brauchen selber Zeit. D.h.: wenn noch während dieser Zeit 
erneut das auszugebende Ereignis auftritt, kommt Mist raus.

Während man beim printf-Debugging mit einer gewissen Erfahrung noch die 
Chance hat, das Auftreten dieses Problems zu erkennen, kann es mit 
beep-Debugging durchaus passieren, dass man GARNIX hört, obwohl (oder 
gerade weil) das Debug-Ereignis mehrere 10000mal pro Sekunde auftritt.

Verstehst du das Problem?

[Bauform B. (bauformb)]

Stefan ⛄ F. schrieb:
> Wenn du schon einen Pin frei hast, um Töne auszugeben, kannst du da auch
> gleich Texte mit UART Protokoll ausgeben.

Wenn das Gerät sowieso eine Hupe braucht, muss der Pin geopfert werden. 
Und dann ist die Hupe sowieso da, während für das UART erstmal 
Pegelwandler, Leiterbahnen und Stecker fehlen.

Harald A. schrieb:
> Du kannst einer Prozedur keine Frequenz übergeben, weil der verwendete
> Mikrocontroller keinen Divisionsbefehl kennt?

Könnte ich natürlich, ich mache ja auch andere sinnlose Sachen ;)

> Erkläre das bitte mal näher…

Im Ernst jetzt? Wenn man die Resonanz des Buzzers treffen will, möchte 
man beep(2400); schreiben. beep() muss dann timertakt/2400 rechnen und 
mit dem Ergebnis ein Timer-Register füttern. In einer Interrupt-Routine 
ist selbst eine Division in Hardware grenzwertig, in Software völlig 
utopisch. Ganz abgesehen von den ca. 800 Byte Flash, wenn man die 
Division aus der libgcc nimmt.

c-hater schrieb:
> Alle diese Debug-Arten haben ein gemeinsames
> Problem: sie brauchen selber Zeit.

Alle Werkzeuge haben ihre Grenzen. Mit vernünftiger Timer-Hardware trägt 
ein beep() aber wirklich wenig auf.

[Bauform B. (bauformb)]

omnna schrieb:
> ich würde mit den Midi-Codes arbeiten.
> https://www.zem-college.de/midi/mc_taben.htm

Damit bekomme ich genau diese Mehrdeutigkeit:

Some manufacturers label the 440 Hz concert pitch
not correctly as A3. It is really A4.

http://www.sengpielaudio.com/calculator-notenames.htm

[c-hater (Gast)]

Bauform B. schrieb:

> Wenn man die Resonanz des Buzzers treffen will, möchte
> man beep(2400); schreiben. beep() muss dann timertakt/2400 rechnen und
> mit dem Ergebnis ein Timer-Register füttern.

Wenn der Compiler den Timertakt bereits kennt, dann kann er das zur 
Compilezeit rechnen. Zur Laufzeit wird dann nur diese vorberechnete 
Konstante in die Hardwareregister geschrieben.

Du musst noch sehr viel lernen...

[Bauform B. (bauformb)]

c-hater schrieb:
> Du musst noch sehr viel lernen...

Deshalb tue ich mir dieses Forum an ;)

[N. M. (mani)]

Es wird ja von Cortex M gesprochen.
Warum legt man da nicht einfach den SWO Pin auf einen Testpunkt?
Hat mir seither immer ausgereicht.
Und man kann definitiv mehr Informationen übertragen als über einen 
Beep.

[Stefan F. (Gast)]

N. M. schrieb:
> Warum legt man da nicht einfach den SWO Pin auf einen Testpunkt?

Der Cortex M0 hat kein SWO.

[Bauform B. (bauformb)]

N. M. schrieb:
> Es wird ja von Cortex M gesprochen.
> Warum legt man da nicht einfach den SWO Pin auf einen Testpunkt?
> Hat mir seither immer ausgereicht.
> Und man kann definitiv mehr Informationen übertragen als über einen
> Beep.

Das eine schließt das andere ja nicht aus. Ein entscheidender Vorteil 
vom beep ist aber der zweite, unabhängige Eingangskanal beim 
Programmierer. Warum wohl gibt es im Flugzeug diverse akustische 
Warnungen? Bildschirme gäbe es da doch reichlich?

Ach, übrigens:
c-hater schrieb:
> Wenn der Compiler den Timertakt bereits kennt, dann kann er das zur
> Compilezeit rechnen. Zur Laufzeit wird dann nur diese vorberechnete
> Konstante in die Hardwareregister geschrieben.

das genau ist der Plan. Ich suche nur noch nach vernünftigen Namen für 
diese Konstanten. Das war eigentlich meine Frage.

[Stefan F. (Gast)]

dideldadeldü = Akku wird schwach
dadeldideldü = Getriebe klemmt
dadeldüdeldi = Zu wenig Wasser
düdeldadelda = Zu viel Wasser

Sorry, das kann sich doch kein Mensch merken. Wie notiert man so etwas 
auf verständliche Weise? (war ja auch deine Eingangsfrage)

Und das waren nur 4 verschiedene Frequenzen. Wie viele wolltest du 
nutzen?

[N. M. (mani)]

Stefan ⛄ F. schrieb:
> Der Cortex M0 hat kein SWO.

Ah, dann hatte ich das falsch gespeichert.

[c-hater (Gast)]

Bauform B. schrieb:

> Warum wohl gibt es im Flugzeug diverse akustische
> Warnungen? Bildschirme gäbe es da doch reichlich?

Weil die Piloten i.d.R. nach vorn zu schauen haben, die Instrumente 
bekommen nur ab und an einen Blick. Ist wie im Auto, auch da guckt man 
meist nach vorn und nur gelegentlich mal auf den Tacho oder die 
Tankanzeige.

Übrigens ist im Flugzeug ganz klar geregelt, was akustisch signalisiert 
werden darf und es gibt eine strikte Priorisierung beim gleichzeitigen 
Anliegen mehrerer akustischer Notifikationen. Die Designer dieser 
Schnittstelle haben halt (im Gegensatz zu dir) über die Implikationen 
NACHGEDACHT.

> das genau ist der Plan. Ich suche nur noch nach vernünftigen Namen für
> diese Konstanten. Das war eigentlich meine Frage.

Dann hättest du die Implementierung von beep() zeigen müssen. Denn da 
dürfte diese Konstante bereits benutzt werden...

[Irgend W. (Firma: egal) (irgendwer)]

Stefan ⛄ F. schrieb:
> dideldadeldü = Akku wird schwach
> dadeldideldü = Getriebe klemmt
> dadeldüdeldi = Zu wenig Wasser
> düdeldadelda = Zu viel Wasser
> Sorry, das kann sich doch kein Mensch merken. Wie notiert man so etwas
> auf verständliche Weise? (war ja auch deine Eingangsfrage)

Wie beschissen das ganze in der Realität funktioniert kennt jeder der 
schonmal mit PC herumgebastelt hat. Spätestens beim zweiten mal hat man 
sich eine Diagnosekarte besorgt, die einem das im "Klartext" anzeigt:-)

https://de.wikipedia.org/wiki/Liste_der_BIOS-Signalt%C3%B6ne

Bauform B. schrieb:
> Auch ein unmusikalischer
> Programmierer kann mehr als 3 Tonhöhen unterscheiden.

Aber nur wenn die drei Töne nacheinander abspielt werden, damit man 
einen Vergleich hat. Bei einem einzelnen Ton wird es schon zu 
Fehleinschätzungen kommen. Da kannst du in deiner Beschreibung gerne 
schreiben das da eine 440Hz Ton ausgegeben wird. Viele werden dir ohne 
Vergleich (oder Messgerät:-) aber auch eine 220Hz oder 880Hz Ton als 
solchen identifizieren. Zweit Töne die extrem weit auseinander liegen 
mag noch gehen, mehr darfst du Ottonormalo aber nicht zumuten.

https://de.wikipedia.org/wiki/Liste_der_BIOS-Signalt%C3%B6ne#MR-BIOS

[PittyJ (Gast)]

Bauform B. schrieb:
> Soweit so gut und in der Praxis bewährt. Bei einem Cortex-M0 kann man
> beep() keine Frequenz übergeben weil der keinen Divisionsbefehl hat. Na
> gut, übergibt man eben direkt den Wert den der Timer braucht, z.B. 4545
> für ein a'. Dafür braucht man aber Namen, ein paar Konstanten. Aber wie
> schreibt man das in C?

Quatsch. Das konnte schon mein Z80 vor 40 Jahren. Und der hatte 
definitiv keinen Divisionsbefehl.

[Bauform B. (bauformb)]

Irgend W. schrieb:
> Da kannst du in deiner Beschreibung gerne
> schreiben das da eine 440Hz Ton ausgegeben wird. Viele werden dir ohne
> Vergleich (oder Messgerät:-) aber auch eine 220Hz oder 880Hz Ton als
> solchen identifizieren. Zweit Töne die extrem weit auseinander liegen
> mag noch gehen

Na gut, einigen wir uns auf drei. Und manchmal ist ja sogar Zeit genug 
für einen Dreiklang.

Aber was an "debugging" und "Programmierer" ist eigentlich so schwer zu 
verstehen? Im Notfall werden ein bis drei beep() eingebaut, der Fehler 
gefunden und die Töne wieder vergessen. Für den User war das überhaupt 
nicht gedacht.

Andererseits könnte das auch für Benutzer nützlich sein:
Stefan ⛄ F. schrieb:
> dideldadeldü = Akku wird schwach
> dadeldideldü = Getriebe klemmt
> dadeldüdeldi = Zu wenig Wasser
> düdeldadelda = Zu viel Wasser
>
> Sorry, das kann sich doch kein Mensch merken.

So merkbefreit sind Menschen doch auch nicht. Zu "dideldadeldü" kommt ja 
noch die rote Lampe und irgendwann hat er den Zusammenhang gelernt. Bis 
dahin sagt der Lärm nur "schau mal auf's Display und mach was!".

[omnna (Gast)]

>Damit bekomme ich genau diese Mehrdeutigkeit:
Ich meinte den Midi Code. 0,1,2 usw.

Aber auch die Noten sind doch eindeutig. Musst halt nur sagen, wonach 
man sich richten muss. ...B, Bflat, H
https://en.wikipedia.org/wiki/Scientific_pitch_notation

[Wilhelm M. (wimalopaan)]

Ich hatte das mal so gemacht:

    constexpr note c_ii_1 {Pitch{Letter::c}, Length{Base::whole}};
    constexpr note c_s_ii_1 {Pitch{Letter::c, Octave::ii, Accidential::sharp}, Length{Base::whole}};
    constexpr note d_ii_1 {Pitch{Letter::d}, Length{Base::whole}};

// ...    
    constexpr note pause_4 {Pitch{Letter::pause}, Length{Base::quarter}};
    constexpr note pause_1 {Pitch{Letter::pause}, Length{Base::whole}};
    
    constexpr auto startMelody = AVR::Pgm::Array<note, c_ii_1, d_ii_1, e_ii_1, f_ii_1, g_ii_1, a_ii_1, h_ii_1, c_iii_1>{}; // C-Dur up

// ...

[c-hater (Gast)]

Wilhelm M. schrieb:
> Ich hatte das mal so gemacht:
>
>

>     constexpr note c_ii_1 {Pitch{Letter::c}, Length{Base::whole}};
>     constexpr note c_s_ii_1 {Pitch{Letter::c, Octave::ii, 
> Accidential::sharp}, Length{Base::whole}};
>     constexpr note d_ii_1 {Pitch{Letter::d}, Length{Base::whole}};
> 
> // ...
>     constexpr note pause_4 {Pitch{Letter::pause}, 
> Length{Base::quarter}};
>     constexpr note pause_1 {Pitch{Letter::pause}, Length{Base::whole}};
> 
>     constexpr auto startMelody = AVR::Pgm::Array<note, c_ii_1, d_ii_1, 
> e_ii_1, f_ii_1, g_ii_1, a_ii_1, h_ii_1, c_iii_1>{}; // C-Dur up
> 
> // ...
>

Na toll, dann ist ja schonmal ein wichtiger Teil für einen 
Westminster-Gong vorhanden. Nun musst du ihn nur noch auf einem Tiny85 
umsetzen, dann hast du meine uneingeschränkte Anerkennung.

Bis dahin allerdings ist das für mich nur eins: schwachsinniges und 
nutzloses C++-Syntax-Gewichse, was niemand lesen kann außer den Leuten, 
die ihren Tag damit vertrödeln (müssen), sich mit sowas 
auseinanderzusetzen...

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>> Ich hatte das mal so gemacht:
>>
>>

>>     constexpr note c_ii_1 {Pitch{Letter::c}, Length{Base::whole}};
>>     constexpr note c_s_ii_1 {Pitch{Letter::c, Octave::ii,
>> Accidential::sharp}, Length{Base::whole}};
>>     constexpr note d_ii_1 {Pitch{Letter::d}, Length{Base::whole}};
>>
>> // ...
>>     constexpr note pause_4 {Pitch{Letter::pause},
>> Length{Base::quarter}};
>>     constexpr note pause_1 {Pitch{Letter::pause}, Length{Base::whole}};
>>
>>     constexpr auto startMelody = AVR::Pgm::Array<note, c_ii_1, d_ii_1,
>> e_ii_1, f_ii_1, g_ii_1, a_ii_1, h_ii_1, c_iii_1>{}; // C-Dur up
>>
>> // ...
>>

>
> Na toll, dann ist ja schonmal ein wichtiger Teil für einen
> Westminster-Gong vorhanden. Nun musst du ihn nur noch auf einem Tiny85
> umsetzen, dann hast du meine uneingeschränkte Anerkennung.

Danke, läuft auch auf dem Tiny85 ...


> Bis dahin allerdings ist das für mich nur eins: schwachsinniges und
> nutzloses C++-Syntax-Gewichse, was niemand lesen kann außer den Leuten,
> die ihren Tag damit vertrödeln (müssen), sich mit sowas
> auseinanderzusetzen...

... denn alles was aus dem Gewichse raus kommt sind ein paar uint16_t im 
PGM für einen Timer.

[Noch ein Kommentar (Gast)]

Auf die Bios Beep Codes hatte IBM doch bestimmt ein Patent angemeldet.

Wir sollten erst mal schauen, ob wir bei IBM eine komplette PC Lizenz 
kaufen müssen, damit wir Fehlermeldungen als Töne ausgeben dürfen.

[Peter D. (peda)]

c-hater schrieb:
> Übrigens ist im Flugzeug ganz klar geregelt, was akustisch signalisiert
> werden darf und es gibt eine strikte Priorisierung beim gleichzeitigen
> Anliegen mehrerer akustischer Notifikationen. Die Designer dieser
> Schnittstelle haben halt (im Gegensatz zu dir) über die Implikationen
> NACHGEDACHT.

Wobei das auch schon auf die harte Tour gelernt wurde, z.B. der Warnton 
für zu geringen Kabinendruck fehlinterpretiert wurde und beide Piloten 
ohnmächtig wurden.
Die Analysen auf Mentour Pilot sind schon recht interessant. Auch wenn 
in 4 Checklisten der Schalter zu überprüfen ist, kann er danach immer 
noch falsch stehen.

[c-hater (Gast)]

Wilhelm M. schrieb:

> ... denn alles was aus dem Gewichse raus kommt sind ein paar uint16_t im
> PGM für einen Timer.

Aha. Ich wollte aber eher was, was ich deutlich mehr wie das Original 
anhört, etwa so:

https://www.mikrocontroller.net/attachment/451883/Hoerbeispiel_twelve_o_clock.mp3

Viel leichter zu lesen als diese C++-Gülle und ein viel besseres 
Ergebnis...

[c-hater (Gast)]

Peter D. schrieb:

> Wobei das auch schon auf die harte Tour gelernt wurde

Das ist ohne jeden Zweifel so. Wo Menschen arbeiten, werden unweigerlich 
auch Fehler gemacht. Aber man kann halt aus diesen Fehlern lernen und 
das Konzept verfeinern.

Man muss aber eben erstmal ein sinnvolles Grundkonzept haben.

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> ... denn alles was aus dem Gewichse raus kommt sind ein paar uint16_t im
>> PGM für einen Timer.
>
> Aha. Ich wollte aber eher was, was ich deutlich mehr wie das Original
> anhört, etwa so:

Ich spare mir den restlichen C++-Porno und das andere Gewichse hier zu 
posten, denn es ging ja nur um die Notation und Definition.

> Viel leichter zu lesen als diese C++-Gülle und ein viel besseres
> Ergebnis...

Ach so, Du kannst dem C++ Gewichse ansehen, wie es klingt. Du bist ja 
echt ein irrer Typ. Dann zeigt doch mal Deinen asm-Dünnschiss, damit ich 
mir auch einen visuellen Eindruck verschaffen kann ;-)

[c-hater (Gast)]

Wilhelm M. schrieb:

> Ach so, Du kannst dem C++ Gewichse ansehen, wie es klingt.

Natürlich kann ich das. Du hast ja selber die Grenzen des Möglichen 
vorgegeben mit:

>> raus kommt sind ein paar uint16_t im
>> PGM für einen Timer

Damit ist klar, das nur Rechteck-Gepiepse das Ergebnis sein kann.

> Du bist ja
> echt ein irrer Typ. Dann zeigt doch mal Deinen asm-Dünnschiss, damit ich
> mir auch einen visuellen Eindruck verschaffen kann ;-)

Die Sources sind im Thread enthalten.

Beitrag "Re: Westminster Soundgenerator mit ATtiny85"

Ja, sie sind nicht komplett durchgestyled. Wenn das nicht nur ein 
Hobbyprojekt gewesen wäre, müsste man noch etwas nachbessern.

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Ach so, Du kannst dem C++ Gewichse ansehen, wie es klingt.
>
> Natürlich kann ich das. Du hast ja selber die Grenzen des Möglichen
> vorgegeben mit:
>
>>> raus kommt sind ein paar uint16_t im
>>> PGM für einen Timer
>
> Damit ist klar, das nur Rechteck-Gepiepse das Ergebnis sein kann.

Mehr war lt. TO nicht gefordert, eine Notation für attack und decay war 
nicht angesagt.

Du hast immer noch nicht Deine Notation für beliebige Töne beschränkt 
leider auf Tonhöhe und -länge nicht gezeigt.

>> Du bist ja
>> echt ein irrer Typ. Dann zeigt doch mal Deinen asm-Dünnschiss, damit ich
>> mir auch einen visuellen Eindruck verschaffen kann ;-)
>
> Die Sources sind im Thread enthalten.
>
> Beitrag "Re: Westminster Soundgenerator mit ATtiny85"
>
> Ja, sie sind nicht komplett durchgestyled. Wenn das nicht nur ein
> Hobbyprojekt gewesen wäre, müsste man noch etwas nachbessern.

Ach Gott, Du arme Kreatur: musstest Du diese ganzen Wichstabellen 
außerhalb, mit anderen Werkzeugen als asm ergießen? Das ist ja echt 
armselig.

[c-hater (Gast)]

Wilhelm M. schrieb:

> Ach Gott, Du arme Kreatur: musstest Du diese ganzen Wichstabellen
> außerhalb, mit anderen Werkzeugen als asm ergießen? Das ist ja echt
> armselig.

Das kann sich ja eigentlich nur auf die Lookup-Tabellen für den Sinus 
und die Multiplikation beziehen. Die hätte ich auch allein mit dem 
Assembler realisieren können. Würde nur viel mehr Arbeit machen, als 
einfach Excel dafür zu benutzen.

Der Rest ist natürlich nicht mit dem Assembler zu lösen (und auch mit 
keiner anderen Sprache). Die Analyse des Originalsignals muss man schon 
mit einem geeigneten Programm erledigen. Was ich natürlich auch selber 
geschrieben habe. Und damit du richtig abkotzt: auch wieder nicht in 
C++, sondern in VB.net. Geht viel einfacher, weniger fehlerträchtig und 
komfortabler.

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Ach Gott, Du arme Kreatur: musstest Du diese ganzen Wichstabellen
>> außerhalb, mit anderen Werkzeugen als asm ergießen? Das ist ja echt
>> armselig.
>
> Das kann sich ja eigentlich nur auf die Lookup-Tabellen für den Sinus
> und die Multiplikation beziehen. Die hätte ich auch allein mit dem
> Assembler realisieren können. Würde nur viel mehr Arbeit machen, als
> einfach Excel dafür zu benutzen.

Siehste, in C++ macht das zur Compile-Zeit eben keine große Arbeit ;-)

>
> Der Rest ist natürlich nicht mit dem Assembler zu lösen (und auch mit
> keiner anderen Sprache).
> ...
> sondern in VB.net. Geht viel einfacher, weniger fehlerträchtig und
> komfortabler.

Widerspruch in sich. Das hat, wie Du merkst, gar nichts mit der Sprache 
zu tun (sofern diese turing-vollständig ist).
Natürlich könnte man das zu Compiler-Zeit in C++: die einzige 
Voraussetzung ist, dass die originalen Samples als e.g. Array-Definition 
etwa in vorliegen.
Und VB.net Ergüsse weniger fehlerträchtig als C++: jetzt darfst Du echt 
aufwischen kommen!

[c-hater (Gast)]

Wilhelm M. schrieb:

> jetzt darfst Du echt
> aufwischen kommen!

Ach, ich wische auf, wenn du DAS vollständig und tatsächlich in Echtzeit 
funktionsfähig in C++ umgesetzt hast...

Du musst nicht linkswichsen und dir über die Tabellen-Generierung 
irgendeinen Kopf machen und du musst sich ganz sicher auch nicht mit 
unnützer C++-Syntax "anreichern". Du darfst sie einfach "as is" 
übernehmen...

Auch alles Wissen aus dem Originalsignal, größtenteils in (sic) 
C-style-Macros und Byte-Arrays, darfst du einfach so übernehmen.

Spannend ist einzig: bekommst du mit SO VIEL Hilfe und Vorarbeit eine 
Lösung in C++ gebacken?

Ich bin schon sowas von gespannt...

[Stefan F. (Gast)]

Arduino Fanboy schrieb im Beitrag #7072765:
> Muahahah. Psst...das 21. ist längst vorbei, wir sind bereits im 22.
> Jahrhundert.

Uppsallalala

[c-hater (Gast)]

c-hater schrieb:

> Ich bin schon sowas von gespannt...

Insbesondere unter der Voraussetzung, das heutige Compiler ja praktisch 
perfekt optimierend sind, wie immer wieder behauptet wird. Nicht zuletzt 
von dir selber...

Da sollte das ganze ja keinerlei Problem darstellen. Einfach den Code 
nachbauen und alles sollte laufen...

Zumal er auch noch überaus geschwätzig dokumentiert ist. Für mich selber 
hätte ich nichtmal ein Zehntel davon dokumentiert.

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> jetzt darfst Du echt
>> aufwischen kommen!
>
> Ach, ich wische auf, wenn du DAS vollständig und tatsächlich in Echtzeit
> funktionsfähig in C++ umgesetzt hast...

...

> Spannend ist einzig: bekommst du mit SO VIEL Hilfe und Vorarbeit eine
> Lösung in C++ gebacken?

Ja, das WÄRE eine challenge, leider ist Corona vorbei und jetzt ist 
Sommer, da habe ich besseres zu tun (Wichsen und GB ... Du weißt schon).

[c-hater (Gast)]

Wilhelm M. schrieb:

> Ja, das WÄRE eine challenge, leider ist Corona vorbei und jetzt ist
> Sommer, da habe ich besseres zu tun

Sprich: du kneifst. Und zwar schon bevor du es auch nur versucht hast. 
Weil dir klar ist, dass ich sehr wohl weiß, wovon ich rede und ganz 
bewußt etwas an der Grenze des Machbaren implementiert habe...

[Norbert (Gast)]

Bauform B. schrieb:
> printf-debugging war gestern, beep-debugging regelt!

OK, neue Idee: Roboter Arm mit Plastik-Hand die einem bei »division by 
zero« rechts und links in die Fres……

OK, neue Idee: über den Debug Port Dildo ansteuern. Den kann man sich 
dann in den …
… weil manchmal ist debuggen echt für'n Ar…

OK, neue Idee:
...

Irgendwie seltsam wenn mittlerweile die ganze Woche Freitag ist!

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Ja, das WÄRE eine challenge, leider ist Corona vorbei und jetzt ist
>> Sommer, da habe ich besseres zu tun
>
> Sprich: du kneifst. Und zwar schon bevor du es auch nur versucht hast.
> Weil dir klar ist, dass ich sehr wohl weiß, wovon ich rede und ganz
> bewußt etwas an der Grenze des Machbaren implementiert habe...

Ja sicher, Du bist der Größte in ASM. Das gebe ich neidlos zu! 
Jedenfalls habe ich nicht einmal einen Bruchteil so viel Ahnung davon, 
wie Du. Ich kann es gerade mal lesen, geschweige denn etwas effizientes 
selbst schreiben.

Eigentlich ist meine Ära es Uhrenselbstbaus (wie würdest Du sagen: des 
Uhren-Wichsens) schon lange vorbei. Und die Zeit der alten Tinys ist für 
mich auch schon lange vorbei. Also, sehr schlechte Voraussetzungen, um 
mit Dir mit zu halten. Und die 8K sind ganz voll bei Dir? Da bin ich 
weise genug, um zu sagen: das schaffe ich mit C++ nicht (abgesehen 
davon, dass ich ja wegen der ganzen Wichserei keine Zeit habe).

[Stefan F. (Gast)]

Die Ausdrucksweise vom c-hater würde nicht einmal die AFD in ihren 
Reihen dulden.

[Wilhelm M. (wimalopaan)]

Stefan ⛄ F. schrieb:
> Die Ausdrucksweise vom c-hater würde nicht einmal die AFD in ihren
> Reihen dulden.

... habe ja versucht, mich anzupassen.

Aber auch da muss ich neidlos gestehen, dass er mir da um Lichtjahre 
"voraus" (oder "hinten drin") ist.

[c-hater (Gast)]

Wilhelm M. schrieb:

> Ja sicher, Du bist der Größte in ASM.

Bin ich nicht. Es gibt Leute, die besser sind als ich. Ich kann das 
einschätzen, du allerdings nicht.

> Jedenfalls habe ich nicht einmal einen Bruchteil so viel Ahnung davon,
> wie Du. Ich kann es gerade mal lesen, geschweige denn etwas effizientes
> selbst schreiben.

Sollst du ja auch nicht. Du sollst es in der Sprache schreiben, wo du 
der Ober-Guru bist (jedenfalls nach deiner Selbsteinschätzung). Und du 
hast als Ausgangspunkt einen praktisch bis zu einzelnen Instruktion 
untersetzt kommentierten Quelltext und alle nötigen Daten. Das sollte 
doch machbar sein. Ist es natürlich, ich könnte das jedenfalls, es wird 
nur am Ende nicht laufen (egal, ob ich es mache oder so ein C++-Oberguru 
wie du) und genau das ist der Punkt!

> Eigentlich ist meine Ära es Uhrenselbstbaus (wie würdest Du sagen: des
> Uhren-Wichsens) schon lange vorbei

Meine natürlich auch.

> Und die Zeit der alten Tinys ist für
> mich auch schon lange vorbei.

Ausflüchte. auch bei "größeren" MCUs und CPUs wird liebevoll und 
kompetent umgesetzter Assembler immer besser sein können als die 
Produkte eines Compilers. Eben entgegen der penetrant bis zum Abkotzen 
wiederholten LÜGE, die das Gegenteil behauptet.

Genau dazu, dies zu zeigen, diente das Projekt. Naja und dazu, mir die 
corona-induzierte Langeweile zu vertreiben...

> Und die 8K sind ganz voll bei Dir? Da bin ich
> weise genug, um zu sagen: das schaffe ich mit C++ nicht

Wetten, wenn das Ergebnis wenigstens näherungsweise in der Echtzeit 
bleiben und annähernd die Wiedergabe-Qualität des Asm-Programms 
erreichen soll?

Ich nehme das aber mal als Versprechen und bin meinerserseits gern 
bereit, deine bahnbrechenden Ideen (so es sie tatächlich gibt) wiederum 
nach Asm zurück zu portieren. Natürlich mit Quellenangabe und explizitem 
Lob. Jedem das Seine.

Wäre ja richtig geil, wenn dir wirklich was deutlich Effizienteres 
einfiele. Da wäre dann vielleicht sogar Luft für den 12. 
Synthesizerkanal (dessen Daten ich bereits habe, für den bloß die 
Rechenzeit nicht gereicht hat). Das würde das Ergebnis schon etwas 
verbessern.

Oder (noch viel besser): Luft zur Verdoppelung der Samplerate. Das wäre 
der Überkracher, dann könnte das Ergebnis nämlich sogar richtig gut 
werden nd nicht nur so lala wie das der gegenwärtigen Lösung.

Aber leider: all das wird leider nicht passieren. Du wirst nicht mal den 
Nachbau lauffähig gebacken bekommen.

[Nosnibor (Gast)]

Also Pieptöne erzeugen, die auch von alleine wieder aufhören, das 
braucht ja doch wieder irgendeine Zustandsmaschine, irgendeinen 
Interrupt oder sowas… da kann ich auch gleich bei meinem UART-Treiber 
mit Ringpuffer bleiben für printf() auch im Interrupt.

Aber man sollte "das Oszilloskop des kleinen Mannes" (Piezo-Speaker) 
nicht unterschätzen, das kann gelegentlich sehr nützlich sein. Zwei 
Beispiele:

1. Piezo parallel zur "activity"-LED eines Ethernetchips. Das ist schon 
ca. 20 Jahre her, damals gab es noch ehrliche "activity"-LEDs (und 
weniger MDNS-Spam im LAN); das gab dann also für jedes Netzwerkpaket 
einen Knackser. Die charakteristischen Rhythmen für typische Situationen 
hat man schnell gelernt, und dann war es einfach praktisch, die 
Information zu bekommen, ohne dafür die Augen zu brauchen.

2. Piezo via 10k-Poti als Spannungsteiler am RS-485-Bus. Das Poti 
reduziert die Lärmbelästigung für die Kollegen und die kapazitive Last 
für die RS-485-Treiber (ein Piezo hat ca. 10-100nF). Das kann einem 
einen schnellen Überblick verschaffen, wiederum ohne hinsehen zu müssen 
(Baudrate, verschlüsselt oder Klartext, Handshake-Problem oder 
polling-Normalbetrieb…).

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Bauform B. schrieb:
> während für das UART erstmal
> Pegelwandler, Leiterbahnen und Stecker fehlen.

In welchen Jahrhundert lebst du? Heute nimmt man fertige Platinchen, auf 
denen UART-USB bestückt ist und man zwischen 3,3V und 5V umschalten kann 
- kein Pegelwandler nötig.
Leiterbahnen wirst du für deinen Summer sicher auch brauchen. Dafür 
erlaubt UART eine detailierte Ausgabe von z.B. Variablen, Strings oder 
Status. Mach das mal mit Buzzer.

[Cptn Cisco (Gast)]

> während für das UART erstmal
> Pegelwandler, Leiterbahnen und Stecker fehlen.
Kaese.

Der (Soft-)UART macht (Fast-)IRDA an eine LED.
Das kann im fertigen Geraet spaeter auch die Pauer-LED sein.
Aufwand: Widerstand+LED+Code wenn nicht sowieso schon da.
Ausserdem: Potentialtrennend und auch fuer HV geeignet.

> damals gab es noch ehrliche "activity"-LEDs
Ein snoop -a auf dem richtigen Rechner und mit dem
richtigen System kann das uebrigens auch.

[Noch ein Kommentar (Gast)]

> In welchen Jahrhundert lebst du? Heute nimmt man...

Ähmm... das war damals, bevor die Chinesen den Hafen von Shanghai 
sperrten.

Jetzt kommen keine Platinchen mehr nach und wir müssen wider auf DDR 
Improvisationen zurück greifen.

[Bauform B. (bauformb)]

Danke für die vielen Ideen, was man alles bauen könnte ;) Dazwischen 
wären die 4% Antworten auf meine Frage fast untergegangen, also ein 
extra Danke dafür:
omnna schrieb:
> ich würde mit den Midi-Codes arbeiten.
> https://www.zem-college.de/midi/mc_taben.htm
und besonders dafür, das ist ja tatsächlich ein Standard:
omnna schrieb:
> https://en.wikipedia.org/wiki/Scientific_pitch_notation

[Nachdenklicher (Gast)]

Stefan ⛄ F. schrieb:
> dideldadeldü = Akku wird schwach
> dadeldideldü = Getriebe klemmt
> dadeldüdeldi = Zu wenig Wasser
> düdeldadelda = Zu viel Wasser

Und um das zu verstehen, braucht man dann das Jodeldiplom. 😂

[Cptn Cisco (Gast)]

> wären die 4% Antworten

Dir sollte eher zu denken geben, was die anderen 96% davon halten.

Das Noten mit ihrem Namen und ihrer Oktave benummert werden,
sollte eigentlich schon Teil der Allgemeinbildung sein.
Das klangliche Resultat aus Rechtecken macht musikalisch
sowieso nichts her. Damit koennte man nicht einmal die in
analogen Telefonen vorhandenen Klingelton-ICs ueberzeugend
emulieren.