Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
Hihi
Geht es Arduiono ist stille im Saloon....
Ich habs gefunden, prog_char soll man ersetzen durch const char, dann soll es gehen. Mal sehen, ob der kompilierte Schmuddel funktioniert.
Geht es Arduiono ist stille im Saloon....
Ich habs gefunden, prog_char soll man ersetzen durch const char, dann soll es gehen. Mal sehen, ob der kompilierte Schmuddel funktioniert.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Ich muss mich hier mal etwas über die besch******* Arduino-Libraries auslassen, die mitgeliefert werden. Insbesondere die USB-Keyboard-Library.
Ich bin ja dabei, eine IR-Fernbedienung an meinen PC zu häkeln. Die Idee ist, dass der Arduino (Pro Micro mit einem Atmega32U4) die Infrarotsignale empfängt und dekodiert. Der hängt außerdem an einem USB-Port und gibt sich als Tastatur aus. Eigentlich ja ganz einfach, eine IR-Empfangs-Lib (da https://www.instructables.com/id/USB-IR ... op-Laptop/ gefunden und da https://github.com/z3t0/Arduino-IRremote runterladbar) drauf und je nach Code den entsprechenden Tastencode senden, damit das mein PC-Fernsehglotzprogramm oder der Videoplayer versteht.
Nun ist es aber so, dass diese /$&($)(&$§&%&%$**'*+ Keyboard-Lib nur US-Tastaturen unterstützt und bei einem deutschen Tastaturlayout einigen Blödsinn macht. Nu ja, auch darum hat sich mal jemand gekümmert und deutsche Tastaturen etwas nutzbarer gemacht: https://github.com/MichaelDworkin/Ardui ... ch-library.
Dummerweise gehen immer noch nicht so wichtige (Multimedia-)Tasten wie lauter, leiser, Mute, ...
Auch da hat schon mal jemand was gemacht: https://www.stefanjones.ca/blog/arduino ... edia-keys/ + https://github.com/stefanjones/Arduino/ ... es/arduino. Dummerweise für eine uralte Arduino-Version, so dass bei der aktuellen NIX mehr passt. Glücklicherweise haben die Arduino-Heinis die verschiedenen notwendigen Klassendefinitionen und -Deklarationen so umgewurschtelt, dass sich die Ergänzungen jetzt alle in der neuen deutschen Keyboard-Library vornehmen lassen. Und jetzt endlich versteht mein PC die Infrarotfernbedienung
Ich bin ja dabei, eine IR-Fernbedienung an meinen PC zu häkeln. Die Idee ist, dass der Arduino (Pro Micro mit einem Atmega32U4) die Infrarotsignale empfängt und dekodiert. Der hängt außerdem an einem USB-Port und gibt sich als Tastatur aus. Eigentlich ja ganz einfach, eine IR-Empfangs-Lib (da https://www.instructables.com/id/USB-IR ... op-Laptop/ gefunden und da https://github.com/z3t0/Arduino-IRremote runterladbar) drauf und je nach Code den entsprechenden Tastencode senden, damit das mein PC-Fernsehglotzprogramm oder der Videoplayer versteht.
Nun ist es aber so, dass diese /$&($)(&$§&%&%$**'*+ Keyboard-Lib nur US-Tastaturen unterstützt und bei einem deutschen Tastaturlayout einigen Blödsinn macht. Nu ja, auch darum hat sich mal jemand gekümmert und deutsche Tastaturen etwas nutzbarer gemacht: https://github.com/MichaelDworkin/Ardui ... ch-library.
Dummerweise gehen immer noch nicht so wichtige (Multimedia-)Tasten wie lauter, leiser, Mute, ...
Auch da hat schon mal jemand was gemacht: https://www.stefanjones.ca/blog/arduino ... edia-keys/ + https://github.com/stefanjones/Arduino/ ... es/arduino. Dummerweise für eine uralte Arduino-Version, so dass bei der aktuellen NIX mehr passt. Glücklicherweise haben die Arduino-Heinis die verschiedenen notwendigen Klassendefinitionen und -Deklarationen so umgewurschtelt, dass sich die Ergänzungen jetzt alle in der neuen deutschen Keyboard-Library vornehmen lassen. Und jetzt endlich versteht mein PC die Infrarotfernbedienung
Re: Der AVR-/ARDUINO-Faden
Gibt keinen Grund sich drüber auszulassen. Du hast kein Produkt mit irgendeinem Support gekauft worüber du Anspruch auf alle librarys nach deinen Wünschen hast.
Wird alles von der Community für die Community gemacht.
Und du hast deine Änderung vermutlich nirgends umfangreich dokumentiert und veröffentlicht, wie alle anderen, die den Bedarf vorher hatten, auch. Somit darf sich jeder erneut drüber aufregen, bis irgendwann jemand was Angepasstes zur Verfügung stellt. Du könntest nun diese Person sein.
Für andere Plattformen hättest du das immerhin komplett von Grund auf schreiben dürfen....
Wird alles von der Community für die Community gemacht.
Und du hast deine Änderung vermutlich nirgends umfangreich dokumentiert und veröffentlicht, wie alle anderen, die den Bedarf vorher hatten, auch. Somit darf sich jeder erneut drüber aufregen, bis irgendwann jemand was Angepasstes zur Verfügung stellt. Du könntest nun diese Person sein.
Für andere Plattformen hättest du das immerhin komplett von Grund auf schreiben dürfen....
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Is eben alles von Makern für Maker, da kannste keine Qualität erwarten.
Re: Der AVR-/ARDUINO-Faden
So kann mans auch formulieren
Aber Fritzler, wie war das nochmal mit dem Code den man von STM bereitgestellt bekommt?
Aber Fritzler, wie war das nochmal mit dem Code den man von STM bereitgestellt bekommt?
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Herstellerlibs sind mindestens genauson Dreck.
Das Atmel ASF und Softpack sind auch BÄH.
Ein Detail zum STM32 HAL:
Was haben die bitte geraucht um in die Configstructs uint32_t reinzumachen statt einem getypten enum?
1. typsicher
2. eine gescheide IDE schlägt einem dann die enum Member vor, jetzt kannste das per Hand suchen...
und die Bugs erst.
Auf einem STM32L431 ist die HAL Clock Config im Ar***.
Den Code hat der Cube so erzeugt:
Dadurch war dann die UART Baudrate im Poppes, weil der UARt Init die CLK Warte rückwärts ausließt.
Das Atmel ASF und Softpack sind auch BÄH.
Ein Detail zum STM32 HAL:
Was haben die bitte geraucht um in die Configstructs uint32_t reinzumachen statt einem getypten enum?
1. typsicher
2. eine gescheide IDE schlägt einem dann die enum Member vor, jetzt kannste das per Hand suchen...
und die Bugs erst.
Auf einem STM32L431 ist die HAL Clock Config im Ar***.
Den Code hat der Cube so erzeugt:
Code: Alles auswählen
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
//RCC_OscInitStruct.PLL.PLLM = 1; << wird von CubeMX nicht inited und steht daher auf 0 -> HAL nimmt defaultwert von 2, aber die PLL bekommt 1 im Reg
RCC_OscInitStruct.PLL.PLLN = 10;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
Re: Der AVR-/ARDUINO-Faden
...und damit wieder zurück zum Thema
Wir halten fest: schlechten Code gibts überall. Nimm was du kriegst und lebe damit. Aber auch brauchbaren Code gibt es auf jeder Plattform.
Oder schreib dir alles nach deinen Wünschen selbst. Alles.
Wir halten fest: schlechten Code gibts überall. Nimm was du kriegst und lebe damit. Aber auch brauchbaren Code gibt es auf jeder Plattform.
Oder schreib dir alles nach deinen Wünschen selbst. Alles.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Zunächst mal sind die Libraries eigentlich schon gut abgehangen und Tastaturlayouts abseits vom US-Layout sind ja auch nicht ganz neu. Deshalb hätte ich jetzt schon wesentlich mehr erwartet. Ist aber eher so wie auf dem RasPi das raspistill, das als Nonplusultra zur Kameraansteuerung angesehen wird, aber eigentlich nur als krudes Demo programmiert wurde und sich auch so verhält.IPv6 hat geschrieben:Und du hast deine Änderung vermutlich nirgends umfangreich dokumentiert und veröffentlicht, wie alle anderen, die den Bedarf vorher hatten, auch. Somit darf sich jeder erneut drüber aufregen, bis irgendwann jemand was Angepasstes zur Verfügung stellt. Du könntest nun diese Person sein.
Was die Veröffentlichung angeht, da müssen wir mal sehen. Wenn sich da zu viele Hürden auftun (nein ich kaufe dafür keinen eigenen Webspace), könnte es schon sein, dass ich das nicht veröffentliche. Ich würde aber gerne...
Dokumentation ist relativ einfach, weil im wesentlichen zusammen kopiert und Klassenaufrufe angepasst.
P.S.: Welche Laus ist dir denn über die Leber gelaufen?
Re: Der AVR-/ARDUINO-Faden
Aber von wem denn genau?Weisskeinen hat geschrieben:Deshalb hätte ich jetzt schon wesentlich mehr erwartet.
Das hat doch irgendwer auch mal erstellt, weil er das gebraucht hat. Und dann hat er es den anderen Nutzern zur Verfügung gestellt, weil er es als nützlich angesehen hatte. Vielleicht hat das später auch mal jemand erweitert oder in die "Standard"bibliotheken aufgenommen. Wenn die Leute halt alle aus den Staaten waren gibts das halt im US Layout. Und nur weil da jemand vor Jahren mal was geschrieben hat heißt das noch lange nicht, dass er das auch weiterhin pflegen muss.
P.S.
Keine Laus über die Leber, wirklich nicht. Mich stört nur das "Meckern" über solche Projekte, die man kostenlos nutzen kann. Und ja, auch ein wenig die Anspruchshaltung. Die Librarys sind nicht beschissen, nur weil sie in deinen Augen unvollständig sind und du sie nicht 1:1 für deine Zwecke nutzen kannst.
Ist doch wie an einem "Zu verschenken" Stand. Ich zahle nichts, hat irgendwer dort hingestellt. Ich kann vielleicht was davon brauchen, dann nehme ich es. Oder ich kann es vielleicht als Grundlage nehmen, um was Neues draus zu machen. Aber ich kann mich nicht beschweren, das nicht genau das dabei ist, was ich gerade brauche.
Anders sieht das durchaus bei Code von Herstellern aus, da kaufe ich schließlich genau das Produkt, weil ich weiß, was es an Support dazu gibt und das sollte dann auch wie angedacht funktionieren. Hinter "Arduino" verbirgt sich aber kein solcher Hersteller, das ist eine open source Hard- und Softwareplattform.
P.P.S.
Ja, der Tag war lang. Höchste Zeit fürs Bett.
Ich wünsche euch eine gute Nacht
Re: Der AVR-/ARDUINO-Faden
Ist das denn ein Problem, das deutsche Layout umzubiegen?
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Das Problem an der Library ist, dass sie eigentlich nur die ersten 128 ASCII-Zeichen in Scancodes umwandelt und alles andere als Sonderbelegungen betrachtet, sog. Modifier, also Strg, Alt, AltGr, .... Die Scancodes einer Tastatur hängen aber von der Lage der Tasten ab, nicht davon, was oben drauf steht. Jetzt liegen aber halt je nach Layout unterschiedliche Tastenfunktionen an den entsprechenden Stellen und die Auswertung ist relativ tief in den Libraries, die auf Libraries aufbauen, die andere Libraries benutzen, die (etc. etc. pp.) vergraben. Der Autor der deutschen Version hat versucht, die wichtigsten Tasten umzumappen und nutzbar zu machen, so dass ein Zeichen aus einem String vom Arduino auch die richtige Ausgabe am auf deutsch eingestellten PC erscheint. Das wurde reichlich komplex und funktioniert wohl nicht für alle gewünschten Zeichen.
Um das Verhalten komplett ordentlich zu machen, mit passenden Codepages oder so, müsste man das wohl alles komplett neu programmieren. Vielleicht hat das sogar schon mal jemand gemacht, das aber dann nicht veröffentlicht (oder ich hab's nicht gefunden, kann auch sein). Als ich mir gestern aber mal die USB-HID-Spezifikationen angesehen habe, könnte ich verstehen, warum nicht. Das ist wohl alles andere als trivial, aber es gibt ja auch viele Leute, die viel besser programmieren können, als ich... (und das auch noch mit mehr Leidenschaft machen, die ist mir in den letzten Jahren etwas abhanden gekommen...)
Um das Verhalten komplett ordentlich zu machen, mit passenden Codepages oder so, müsste man das wohl alles komplett neu programmieren. Vielleicht hat das sogar schon mal jemand gemacht, das aber dann nicht veröffentlicht (oder ich hab's nicht gefunden, kann auch sein). Als ich mir gestern aber mal die USB-HID-Spezifikationen angesehen habe, könnte ich verstehen, warum nicht. Das ist wohl alles andere als trivial, aber es gibt ja auch viele Leute, die viel besser programmieren können, als ich... (und das auch noch mit mehr Leidenschaft machen, die ist mir in den letzten Jahren etwas abhanden gekommen...)
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Guck dir doch mal V-USB an.
Das kann auch eine Tastatur emulieren, direkt auf Fußpilz äh Scancodebene.
Du musst dich sogar um "gedrückt" und "losgelassen" kümmern.
Funktioniert dafür aber auch
Die Subprojekte hießen glaube sogar direkt:
HID-Keys
USB Volume Control
RC-5 Remote
Das kann auch eine Tastatur emulieren, direkt auf Fußpilz äh Scancodebene.
Du musst dich sogar um "gedrückt" und "losgelassen" kümmern.
Funktioniert dafür aber auch
Die Subprojekte hießen glaube sogar direkt:
HID-Keys
USB Volume Control
RC-5 Remote
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Hmmm, ja, muss ich mal machen. Ich hoffe, das passt dann einigermaßen mit den Routinen zusammen, die schon für den nativen USB-Port des 32U4 existieren...
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
NOPE! Null Komma ganich!
V-USB ist USB per GPIO Bitgeklimper
V-USB ist USB per GPIO Bitgeklimper
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Ja, weiß ich. Aber vielleicht (man kann ja mal Glück haben) haben die Programmierer davon auch gewisse Ebenen eingehalten, was wo wie hardwarenah ist und das einigermaßen kompatibel gestaltet. So nach dem Motto: schicke diesen Deskriptor an den Host, packe jene Antwort in den Buffer, der bei der nächsten Anfrage übertragen wird, so was halt. Die eine Implementierung macht das dann in Software und die andere in Hardware... (man wird ja noch mal träumen dürfen...)
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Das is schon schwieriger als du denkst
Haste denn schon das DB zum 32U4 durchgelesen wegen der USB HW?
Haste denn schon das DB zum 32U4 durchgelesen wegen der USB HW?
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Nein habe ich nicht. Ich träume ja von Kompatibilität auf höherer Ebene. Ich wollte da jetzt wirklich nicht zu tief in die Programmierung eines USB-Clients einsteigen. Dafür gibt es zu viele andere Dinge, die ich lieber machen möchte...
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Lärm!
N'abend,
ich bin endlich mal dazu gekommen mich an meinen Lärm-Moderator (shit, schon 3 Jahre her ) ranzusetzen, und habe folgenden Verhau zusammengeklatscht:
Zur Funktion:
Der Sensor zieht bei erreichen von per Trimmer einstellbarem Pegel seinen Ausgang auf LOW. Da das immer nur sehr kurz der Fall ist, hat er einen Puffer, dessen Wert sieht man im Display links. Wird die Schwelle überschritten gibts 20 Abzug, sonst +1 bis der Puffer wieder voll ist. Werte gehen von +50 bis -99. Bei negativem Puffer zählt der Countdown rechts runter, das sind 7 Sekunden, bei jeder vollen Sekunde macht der Lautsprecher einmal Möps.
Wenn der Puffer wieder positiv ist, wird wieder bis 7 hochgezählt, dabei macht der Lautsprecher etwas leiser Mips. Wenn der Puffer negativ ist, leuchten außerdem noch 2 rote Highpower-LED. (unter dem weißen Papier, sonst blendets, proportional zum Pufferwert)
Der Lautsprecher hängt mittlerweile mit nem kleinen Vorwiderstand am L293D weil der Audio Verstärker den ganzen Müll vom Systemtakt und PWM auch verstärkt hat. So ist das Teil jetzt komplett still, wenns nicht gerade über den Lärm meckert. Der Sound ist immernoch gut genug, bzw häßliche Töne sind hier ja erwünscht.
Verwende die [ tone (Pin, Frequenz); noTone (Pin); ] Funktion, je nach Zeit, die das zum Laufen bekommt, macht das unterschiedliche Geräusche, die nicht zwangsweise mit der angegebenen Frequenz in Verbindung stehen. Das tönt jetzt schon ganz brauchbar, verbessern könnte man das aber auch, wenn man wollte.
Wenn der Countdown 0 erreicht gibts nen Alarm (Sequenz aus verschiedenen Tönen) und rechts von der Buffer-Anzeige geht ein Zähler hoch, wie oft schon alarmiert wurde.
Nach dem Alarm wird der Puffer auf 40 und der Countdown auf 2s gesetzt, damits nicht gleich wieder bimmelt. Von der Idee Ultraschall /hohe, für mich nicht hörbare Töne zu verwenden bin ich abgekommen. Störer bekommen einen Moderator (werde mehrere bauen, für bessere räumliche Auflösung) auf den Tisch, und wenn der Zähler bei 5 ist, gibts Strafarbeit, braucht keine unsichtbare Disziplinierung, zumal die auch unbeteiligte trifft.
Ich habs jetzt natürlich noch nicht in freier Wildbahn laufen lassen. Für mich alleine ist es schwierig, einen vollen Kunstsaal zu simulieren. Mit Musik als Lärmquelle klappts jedenfalls. Wenn man die Empfindlichkeit zu hoch stellt, gibts nen Feedback-Loop und der Puffer kommt nicht mehr hoch. Ich hoffe aber, dass das im Gehäuse nachher nicht mehr problematisch ist, weil ich da Dämpfungsmaßnahmen einsetzen werde. Wie laut oder leise es vor Ort wirklich ist kann ich nicht abschätzen.
Ich vermute auch, dass da (spannungsmäßiger)Dreck in der Versorgung die Messung beeinflusst, die PWM der LEDs war mit dem kleinen Verstärker recht deutlich zu hören. Hab mal nen Elko spendiert. Mein Fädelchaos hilft bestimmt auch nicht.
Macht es überhaupt Sinn, zu versuchen, dem Sensor ne sauberere Versorgung zu basteln?
So richtig zufrieden bin ich mit der Pegelmessung und dem dazugehörigen visuellen Feedback noch nicht. Hab mal noch analoge Mikrophon-Bausteine geordert, da sollte sich das ja feiner mit messen lassen. Dann wollt ich den Lautstärke"Zeiger" vllt über Dotmatrix machen. Die ständig wechselnden Zahlen lassen sich eher schlecht lesen und die notwendige Asymmetrie im PlusMinus-Spiel macht ihr übriges. Hat jemand schlaue Ideen, wie man die Pegelmessung etwas sprungärmer und nachvollziehbarer machen könnte?
Grüße
Moritz
ich bin endlich mal dazu gekommen mich an meinen Lärm-Moderator (shit, schon 3 Jahre her ) ranzusetzen, und habe folgenden Verhau zusammengeklatscht:
Zur Funktion:
Der Sensor zieht bei erreichen von per Trimmer einstellbarem Pegel seinen Ausgang auf LOW. Da das immer nur sehr kurz der Fall ist, hat er einen Puffer, dessen Wert sieht man im Display links. Wird die Schwelle überschritten gibts 20 Abzug, sonst +1 bis der Puffer wieder voll ist. Werte gehen von +50 bis -99. Bei negativem Puffer zählt der Countdown rechts runter, das sind 7 Sekunden, bei jeder vollen Sekunde macht der Lautsprecher einmal Möps.
Wenn der Puffer wieder positiv ist, wird wieder bis 7 hochgezählt, dabei macht der Lautsprecher etwas leiser Mips. Wenn der Puffer negativ ist, leuchten außerdem noch 2 rote Highpower-LED. (unter dem weißen Papier, sonst blendets, proportional zum Pufferwert)
Der Lautsprecher hängt mittlerweile mit nem kleinen Vorwiderstand am L293D weil der Audio Verstärker den ganzen Müll vom Systemtakt und PWM auch verstärkt hat. So ist das Teil jetzt komplett still, wenns nicht gerade über den Lärm meckert. Der Sound ist immernoch gut genug, bzw häßliche Töne sind hier ja erwünscht.
Verwende die [ tone (Pin, Frequenz); noTone (Pin); ] Funktion, je nach Zeit, die das zum Laufen bekommt, macht das unterschiedliche Geräusche, die nicht zwangsweise mit der angegebenen Frequenz in Verbindung stehen. Das tönt jetzt schon ganz brauchbar, verbessern könnte man das aber auch, wenn man wollte.
Wenn der Countdown 0 erreicht gibts nen Alarm (Sequenz aus verschiedenen Tönen) und rechts von der Buffer-Anzeige geht ein Zähler hoch, wie oft schon alarmiert wurde.
Nach dem Alarm wird der Puffer auf 40 und der Countdown auf 2s gesetzt, damits nicht gleich wieder bimmelt. Von der Idee Ultraschall /hohe, für mich nicht hörbare Töne zu verwenden bin ich abgekommen. Störer bekommen einen Moderator (werde mehrere bauen, für bessere räumliche Auflösung) auf den Tisch, und wenn der Zähler bei 5 ist, gibts Strafarbeit, braucht keine unsichtbare Disziplinierung, zumal die auch unbeteiligte trifft.
Ich habs jetzt natürlich noch nicht in freier Wildbahn laufen lassen. Für mich alleine ist es schwierig, einen vollen Kunstsaal zu simulieren. Mit Musik als Lärmquelle klappts jedenfalls. Wenn man die Empfindlichkeit zu hoch stellt, gibts nen Feedback-Loop und der Puffer kommt nicht mehr hoch. Ich hoffe aber, dass das im Gehäuse nachher nicht mehr problematisch ist, weil ich da Dämpfungsmaßnahmen einsetzen werde. Wie laut oder leise es vor Ort wirklich ist kann ich nicht abschätzen.
Ich vermute auch, dass da (spannungsmäßiger)Dreck in der Versorgung die Messung beeinflusst, die PWM der LEDs war mit dem kleinen Verstärker recht deutlich zu hören. Hab mal nen Elko spendiert. Mein Fädelchaos hilft bestimmt auch nicht.
Macht es überhaupt Sinn, zu versuchen, dem Sensor ne sauberere Versorgung zu basteln?
So richtig zufrieden bin ich mit der Pegelmessung und dem dazugehörigen visuellen Feedback noch nicht. Hab mal noch analoge Mikrophon-Bausteine geordert, da sollte sich das ja feiner mit messen lassen. Dann wollt ich den Lautstärke"Zeiger" vllt über Dotmatrix machen. Die ständig wechselnden Zahlen lassen sich eher schlecht lesen und die notwendige Asymmetrie im PlusMinus-Spiel macht ihr übriges. Hat jemand schlaue Ideen, wie man die Pegelmessung etwas sprungärmer und nachvollziehbarer machen könnte?
Grüße
Moritz
Re: Der AVR-/ARDUINO-Faden
Für eine Schätzung, wie laut/leise es im Raum ist kann man Apps auf dem Schmierphone nutzen.
Schau mal im Appstore nach Schallpegel.
Beim Testen zu Hause kannst Du dann die gleiche App laufen lassen und mit dem Radio oder so einen entsprechenden Pegel als Background (notfalls rauschen) einstellen.
Schau mal im Appstore nach Schallpegel.
Beim Testen zu Hause kannst Du dann die gleiche App laufen lassen und mit dem Radio oder so einen entsprechenden Pegel als Background (notfalls rauschen) einstellen.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Jo, sone Apps hab ich eh schon gar viele installiert, weil ich das Thema jeden Tag auf der Arbeit habe. Rauschen ist glaub n guter Tip. Habs mal mit Gitarrespielen gestestet und es war schon etwas störrisch. Manchmal hab ich garnicht (bewusst) lauter gespielt und es zählte runter bis zum Alarm, andersrum hat teilweise lauteres Spielen kaum was bewirkt. Beim Rauschen weiß man wenigstens, dass das schonmal nicht die Fehlerquelle ist.
Werd auch mal versuchen, ob ich die Asymmetrie im Pufferverhalten nicht zumindest teilweise ausgleichen kann, indem ich den Sensor empfindlicher stelle.
Werd auch mal versuchen, ob ich die Asymmetrie im Pufferverhalten nicht zumindest teilweise ausgleichen kann, indem ich den Sensor empfindlicher stelle.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Sodele, bin etwas weitergekommen.
Zum Einen hab ich mal mit Pyphox den Pegel im Klassenzimmer gemessen. -30db war angenehm, -20laut, -10 unerträglich. Dann hab ich mir hier in Meinem Musikprogramm Reason nen Synthi "gebastelt", der Rauschen erzeugt und dessen Lautstärke ich mit nem Drehregler einstellen kann. Und dann hab ich mal gleichzeitig gerauscht und Das Gerät zuhören lassen.
Das lief erstmal nicht wie geplant, weil die bereits erwähnte PWM zuviel in die Versorgung reinstört und damit der Lärmsensor anschlägt. Sobald Die LED leuchten hat der Sensor dauerhaft Fehlalarm. Die LED kurz auskommentieren brachte Klarheit, ohne LED kein Problem mehr. Als Workaround leuchten die LED jetzt nurnoch, wenn gerade der Buzzer lärmt. Da jedoch dessen (ekelektrischer) Lärm ebenfalls vom Sensor "gehört" wird, werden während des Buzzens/Leuchtens die Abzugs/Additionswerte auf 0 gesetzt. danach isses wieder +1/-10.
Ich würde gerne das Mikro noch etwas länger stumm schalten damit nicht nur elektrischer, sondern auch akustischer Lärm gemutet wird, aber mit meiner stümperhaften Programmierkenntnis ist das grade alles inline (heißt das so?)
Bin mir noch nichtmal sicher, ob das überhaupt was bringt, oder ich mich nur selber verarsche. Allerdings läuft das jetzt. Gucke DuRöhre
So wie das programmiert ist kommt [ tone(7, 220)] nicht wirklich dazu, seine Frequenz tatsächlich auch abzuspielen. Was man hört ist das An/Aus von tone(7,egalwas), aber wie gesagt fällt mir nicht ein, wie ich das besser lösen soll, mir fehlt das Vokabular...
Die Visualisierung des Lautstärkepuffers ist blöd mit den Zahlen, da such ich noch was anderes, Vllt sone Dot-Matrix, da hab ich nur noch keine mit Max7219 und RGB LED als Paket gefunden. Hat Jemand schon Erfahrungen mit diesen einzeln ansteuerbaren LedStrips?
Ich würd da gerne 10-er Blocks runterschnippeln und dann damit den Puffer in grün(+) und rot(-) anzeigen. Geht das?
Grüße
Mo
Zum Einen hab ich mal mit Pyphox den Pegel im Klassenzimmer gemessen. -30db war angenehm, -20laut, -10 unerträglich. Dann hab ich mir hier in Meinem Musikprogramm Reason nen Synthi "gebastelt", der Rauschen erzeugt und dessen Lautstärke ich mit nem Drehregler einstellen kann. Und dann hab ich mal gleichzeitig gerauscht und Das Gerät zuhören lassen.
Das lief erstmal nicht wie geplant, weil die bereits erwähnte PWM zuviel in die Versorgung reinstört und damit der Lärmsensor anschlägt. Sobald Die LED leuchten hat der Sensor dauerhaft Fehlalarm. Die LED kurz auskommentieren brachte Klarheit, ohne LED kein Problem mehr. Als Workaround leuchten die LED jetzt nurnoch, wenn gerade der Buzzer lärmt. Da jedoch dessen (ekelektrischer) Lärm ebenfalls vom Sensor "gehört" wird, werden während des Buzzens/Leuchtens die Abzugs/Additionswerte auf 0 gesetzt. danach isses wieder +1/-10.
Ich würde gerne das Mikro noch etwas länger stumm schalten damit nicht nur elektrischer, sondern auch akustischer Lärm gemutet wird, aber mit meiner stümperhaften Programmierkenntnis ist das grade alles inline (heißt das so?)
Code: Alles auswählen
if (sevennum == 9 && debSensor < 0 ){
AddiVal = 0; //Feedbackvermeidung
AbzugVal = 0;
//digitalWrite (Buzzer, HIGH) ;// Buzzer On
analogWrite(ledPin1, leuchtVal);
tone (7, 220);
delay (1) ;// Delay 1ms
noTone (7);
//digitalWrite (Buzzer, LOW) ; // Buzzer Off
AddiVal = 1;
AbzugVal = 10;
analogWrite(ledPin1, 0);
}
if (sevennum == 0 && debSensor > 0 && countnumber != 0 && countnumber < 700){
AddiVal = 0; //Feedbackvermeidung
AbzugVal = 0;
analogWrite(ledPin1, 5); //digitalWrite (Buzzer, HIGH) ;// Buzzer On
tone (7, 3000);
//digitalWrite (Buzzer, LOW) ;// Buzzer Off
noTone (7);
AddiVal = 1;
AbzugVal = 10;
analogWrite(ledPin1, 0);
Bin mir noch nichtmal sicher, ob das überhaupt was bringt, oder ich mich nur selber verarsche. Allerdings läuft das jetzt. Gucke DuRöhre
So wie das programmiert ist kommt [ tone(7, 220)] nicht wirklich dazu, seine Frequenz tatsächlich auch abzuspielen. Was man hört ist das An/Aus von tone(7,egalwas), aber wie gesagt fällt mir nicht ein, wie ich das besser lösen soll, mir fehlt das Vokabular...
Die Visualisierung des Lautstärkepuffers ist blöd mit den Zahlen, da such ich noch was anderes, Vllt sone Dot-Matrix, da hab ich nur noch keine mit Max7219 und RGB LED als Paket gefunden. Hat Jemand schon Erfahrungen mit diesen einzeln ansteuerbaren LedStrips?
Ich würd da gerne 10-er Blocks runterschnippeln und dann damit den Puffer in grün(+) und rot(-) anzeigen. Geht das?
Grüße
Mo
Re: Der AVR-/ARDUINO-Faden
für die anzeige würd ich ein zeiger instrument nehmen. ist einfacher.
der delay ist zu kurz und eh blöd, du hältst die schleife ja damit an.
besser wär ein timer mit zeitstempeln.also:
ton an;
time =millis +100..
if time>=millis...........ton aus .
....oder so in der art.
der delay ist zu kurz und eh blöd, du hältst die schleife ja damit an.
besser wär ein timer mit zeitstempeln.also:
ton an;
time =millis +100..
if time>=millis...........ton aus .
....oder so in der art.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Das wäre ja dann analog? Teufelszeug!
Einfach ist nicht unbeding das Kriterium, das soll ja für die Schüler am Tisch (will mindestens 4 davon bauen und im Klassenzimmer an laute Tische positionieren) möglichst eindeutiges und intuitiv verständliches Feedback abliefern. Grünes Licht=alles OK, Rotes =Nope!
Deswegen Designkriterien groß und gut sichtbar, ohne dass es Konzentration beim Ablesen braucht.
okay, danke, werd ich mal probieren. Dass die Schleife angehalten wird, hab ich zähneknirschend in Kauf genommen. Wird keiner nachmessen, ob das jetzt tatsächlich korrekt die Sekunden zählt oder nicht.der delay ist zu kurz und eh blöd, du hältst die schleife ja damit an.
besser wär ein timer mit zeitstempeln.also:
ton an;
time =millis +100..
if time>=millis...........ton aus .
....oder so in der art.
Ich habe mein "PWM auf der Versorgung"- Lärmproblem vorerst gelöst indem ich dem Lärmsensor 330 ohm vor Vcc und 100μF zwischen Gnd und Plus gehängt habe. Quick and dirty Der hört jetzt nurnoch Schall, das werd ich dann mal mit obiger Methode angreifen.
Spätestens wenn die analogen Sensoren da sind, wird das aber nichtmehr reichen. Aber dann könnte ich ja den gleichen Trick wiederverwenden, nur diesmal zwischen dem Großverbraucher(L293D mit Led und Lautsprecher) der seinen Strom halt verschmutzt, und der Messtechnik, die davon abgezwackt gereinigten Strom bekommt?
Separate Wandler für 2x 5V kommt mir doof vor, L293D direkt an den Akku und Vorwiderstände für Lautsprecher und LED wäre noch ne Variante
Re: Der AVR-/ARDUINO-Faden
Ich hätte da ein Arduino-Problem, welches beim Crowdcontrol-Faden aufgetreten jedoch Arduino-spezifisch ist:
(zudem dürften hier mehr Leute reinschauen)
Da gibt es millis() und millis.
Die millis lassen mir keine Ruhe - ohne Arduino ist das blöd, da muss man erst einen ATmega328 in SMD-Ausführung freiluftverdrahten
Aber jetzt:
Sieht im Terminal Monitor so aus:
Was hat es mit millis auf sich?
Bleibt jedenfalls bei 95 - da hilft auch kein Resetten.
Im Netz finde ich nur millis().
Einer von uns beiden ist ein Depp: Das Netz oder ich.
Edit: Eine Erklärung zur Herkunft der millis() im µC eXperiment-Blog.
Und bei stackexchange.
Immerhin ist da eine 95 zu finden
(zudem dürften hier mehr Leute reinschauen)
Da gibt es millis() und millis.
Die millis lassen mir keine Ruhe - ohne Arduino ist das blöd, da muss man erst einen ATmega328 in SMD-Ausführung freiluftverdrahten
Aber jetzt:
Code: Alles auswählen
long unsigned int puffer1;
void setup() {
Serial.begin(115200);
}
void loop() {
Serial.print("millis(): ");
Serial.println(millis());
Serial.print("millis: ");
//Serial.println(millis); //--> wirft: no matching function for call to 'println(long unsigned int (&)())'
puffer1 = millis;
Serial.println(puffer1);
delay(10000);
}
Code: Alles auswählen
millis(): 0
millis: 95
millis(): 10000
millis: 95
millis(): 20000
millis: 95
millis(): 30001
millis: 95
millis(): 40001
millis: 95
millis(): 50001
millis: 95
millis(): 60002
millis: 95
millis(): 70003
millis: 95
millis(): 80004
millis: 95
millis(): 90004
millis: 95
millis(): 100004
millis: 95
millis(): 110005
millis: 95
millis(): 120005
millis: 95
millis(): 130007
millis: 95
millis(): 140007
millis: 95
millis(): 150007
millis: 95
millis(): 160008
millis: 95
millis(): 170009
millis: 95
millis(): 180009
millis: 95
millis(): 190010
millis: 95
millis(): 200010
millis: 95
millis(): 210011
millis: 95
millis(): 220012
millis: 95
millis(): 230012
millis: 95
millis(): 240013
millis: 95
millis(): 250013
millis: 95
millis(): 260014
millis: 95
millis(): 270015
millis: 95
millis(): 280015
millis: 95
millis(): 290016
millis: 95
Bleibt jedenfalls bei 95 - da hilft auch kein Resetten.
Im Netz finde ich nur millis().
Einer von uns beiden ist ein Depp: Das Netz oder ich.
Edit: Eine Erklärung zur Herkunft der millis() im µC eXperiment-Blog.
Und bei stackexchange.
Immerhin ist da eine 95 zu finden
Re: Der AVR-/ARDUINO-Faden
Ist auch so. Warum sich das kompilieren lässt ist mir aber ein Rätsel....
Re: Der AVR-/ARDUINO-Faden
Arduino eben ...
Gegenprobe:
Ergibt im (auf? hinter?) Monitor:
Da ist sie wieder, die Fünfundneunzig.
Und nun alle gemeinsam:
Ergibt folgende Ausgabe:
Die Fünfundneunzig ist schon belegt, die Einhundertsieben ist frei.
Etwas in der Art hätte ich auch erwartet.
Gegenprobe:
Code: Alles auswählen
int puffer2;
int addivari(int, int); // Prototyp
void setup() {
Serial.begin(115200);
}
void loop() {
int (*zeiger)(int, int);
Serial.print("addivari(1, 2): ");
Serial.println(addivari(1, 2));
zeiger = addivari;
Serial.print("zeiger(4, 5): ");
Serial.println(zeiger(4, 5));
Serial.print("zeiger: ");
//Serial.println(zeiger); //--> wirft: no matching function for call to 'println(int (*&)(int, int))'
puffer2 = zeiger;
Serial.println(puffer2);
delay(10000);
}
int addivari(int a, int b){
int c;
c = a + b;
return c;
}
Code: Alles auswählen
addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 95
Und nun alle gemeinsam:
Code: Alles auswählen
long unsigned int puffer1;
int puffer2;
int addivari(int, int); // Prototyp
void setup() {
Serial.begin(115200);
}
void loop() {
Serial.print("millis(): ");
Serial.println(millis());
Serial.print("millis: ");
//Serial.println(millis); //--> wirft: no matching function for call to 'println(long unsigned int (&)())'
puffer1 = millis;
Serial.println(puffer1);
int (*zeiger)(int, int);
Serial.print("addivari(1, 2): ");
Serial.println(addivari(1, 2));
zeiger = addivari;
Serial.print("zeiger(4, 5): ");
Serial.println(zeiger(4, 5));
Serial.print("zeiger: ");
//Serial.println(zeiger); //--> wirft: no matching function for call to 'println(int (*&)(int, int))'
puffer2 = zeiger;
Serial.println(puffer2);
delay(10000);
}
int addivari(int a, int b){
int c;
c = a + b;
return c;
}
Code: Alles auswählen
millis(): 0
millis: 95
addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 107
Etwas in der Art hätte ich auch erwartet.
Ich weiß noch nicht, wonach ich suche. Aber ich fange schon mal an.sysconsol hat geschrieben:Einer von uns beiden ist ein Depp: Das Netz oder ich.
Re: Der AVR-/ARDUINO-Faden
Noch ein Versuch:
Auf der Konsole:
dis2.dump:
Etwas übersichtlicher:
dis3.dump:
Da muss ich erstmal wachsen - das ist mir gerade etwas zu hoch
Code: Alles auswählen
int puffer2;
int addivari(int, int);
void setup() {
}
void loop() {
int (*zeiger)(int, int);
zeiger = addivari;
puffer2 = zeiger;
}
int addivari(int a, int b){
int c;
c = a + b;
return c;
}
Code: Alles auswählen
avr-objdump -D sketch_dec09a.ino.hex -m avr5 >/media/ramdisk/dis2.dump
Code: Alles auswählen
sketch_dec09a.ino.hex: file format ihex
Disassembly of section .sec1:
00000000 <.sec1>:
0: 0c 94 34 00 jmp 0x68 ; 0x68
4: 0c 94 46 00 jmp 0x8c ; 0x8c
8: 0c 94 46 00 jmp 0x8c ; 0x8c
c: 0c 94 46 00 jmp 0x8c ; 0x8c
10: 0c 94 46 00 jmp 0x8c ; 0x8c
14: 0c 94 46 00 jmp 0x8c ; 0x8c
18: 0c 94 46 00 jmp 0x8c ; 0x8c
1c: 0c 94 46 00 jmp 0x8c ; 0x8c
20: 0c 94 46 00 jmp 0x8c ; 0x8c
24: 0c 94 46 00 jmp 0x8c ; 0x8c
28: 0c 94 46 00 jmp 0x8c ; 0x8c
2c: 0c 94 46 00 jmp 0x8c ; 0x8c
30: 0c 94 46 00 jmp 0x8c ; 0x8c
34: 0c 94 46 00 jmp 0x8c ; 0x8c
38: 0c 94 46 00 jmp 0x8c ; 0x8c
3c: 0c 94 46 00 jmp 0x8c ; 0x8c
40: 0c 94 4b 00 jmp 0x96 ; 0x96
44: 0c 94 46 00 jmp 0x8c ; 0x8c
48: 0c 94 46 00 jmp 0x8c ; 0x8c
4c: 0c 94 46 00 jmp 0x8c ; 0x8c
50: 0c 94 46 00 jmp 0x8c ; 0x8c
54: 0c 94 46 00 jmp 0x8c ; 0x8c
58: 0c 94 46 00 jmp 0x8c ; 0x8c
5c: 0c 94 46 00 jmp 0x8c ; 0x8c
60: 0c 94 46 00 jmp 0x8c ; 0x8c
64: 0c 94 46 00 jmp 0x8c ; 0x8c
68: 11 24 eor r1, r1
6a: 1f be out 0x3f, r1 ; 63
6c: cf ef ldi r28, 0xFF ; 255
6e: d8 e0 ldi r29, 0x08 ; 8
70: de bf out 0x3e, r29 ; 62
72: cd bf out 0x3d, r28 ; 61
74: 21 e0 ldi r18, 0x01 ; 1
76: a0 e0 ldi r26, 0x00 ; 0
78: b1 e0 ldi r27, 0x01 ; 1
7a: 01 c0 rjmp .+2 ; 0x7e
7c: 1d 92 st X+, r1
7e: a9 30 cpi r26, 0x09 ; 9
80: b2 07 cpc r27, r18
82: e1 f7 brne .-8 ; 0x7c
84: 0e 94 95 00 call 0x12a ; 0x12a
88: 0c 94 df 00 jmp 0x1be ; 0x1be
8c: 0c 94 00 00 jmp 0 ; 0x0
90: 86 0f add r24, r22
92: 97 1f adc r25, r23
94: 08 95 ret
96: 1f 92 push r1
98: 0f 92 push r0
9a: 0f b6 in r0, 0x3f ; 63
9c: 0f 92 push r0
9e: 11 24 eor r1, r1
a0: 2f 93 push r18
a2: 3f 93 push r19
a4: 8f 93 push r24
a6: 9f 93 push r25
a8: af 93 push r26
aa: bf 93 push r27
ac: 80 91 05 01 lds r24, 0x0105 ; 0x800105
b0: 90 91 06 01 lds r25, 0x0106 ; 0x800106
b4: a0 91 07 01 lds r26, 0x0107 ; 0x800107
b8: b0 91 08 01 lds r27, 0x0108 ; 0x800108
bc: 30 91 04 01 lds r19, 0x0104 ; 0x800104
c0: 23 e0 ldi r18, 0x03 ; 3
c2: 23 0f add r18, r19
c4: 2d 37 cpi r18, 0x7D ; 125
c6: 58 f5 brcc .+86 ; 0x11e
c8: 01 96 adiw r24, 0x01 ; 1
ca: a1 1d adc r26, r1
cc: b1 1d adc r27, r1
ce: 20 93 04 01 sts 0x0104, r18 ; 0x800104
d2: 80 93 05 01 sts 0x0105, r24 ; 0x800105
d6: 90 93 06 01 sts 0x0106, r25 ; 0x800106
da: a0 93 07 01 sts 0x0107, r26 ; 0x800107
de: b0 93 08 01 sts 0x0108, r27 ; 0x800108
e2: 80 91 00 01 lds r24, 0x0100 ; 0x800100
e6: 90 91 01 01 lds r25, 0x0101 ; 0x800101
ea: a0 91 02 01 lds r26, 0x0102 ; 0x800102
ee: b0 91 03 01 lds r27, 0x0103 ; 0x800103
f2: 01 96 adiw r24, 0x01 ; 1
f4: a1 1d adc r26, r1
f6: b1 1d adc r27, r1
f8: 80 93 00 01 sts 0x0100, r24 ; 0x800100
fc: 90 93 01 01 sts 0x0101, r25 ; 0x800101
100: a0 93 02 01 sts 0x0102, r26 ; 0x800102
104: b0 93 03 01 sts 0x0103, r27 ; 0x800103
108: bf 91 pop r27
10a: af 91 pop r26
10c: 9f 91 pop r25
10e: 8f 91 pop r24
110: 3f 91 pop r19
112: 2f 91 pop r18
114: 0f 90 pop r0
116: 0f be out 0x3f, r0 ; 63
118: 0f 90 pop r0
11a: 1f 90 pop r1
11c: 18 95 reti
11e: 26 e8 ldi r18, 0x86 ; 134
120: 23 0f add r18, r19
122: 02 96 adiw r24, 0x02 ; 2
124: a1 1d adc r26, r1
126: b1 1d adc r27, r1
128: d2 cf rjmp .-92 ; 0xce
12a: 78 94 sei
12c: 84 b5 in r24, 0x24 ; 36
12e: 82 60 ori r24, 0x02 ; 2
130: 84 bd out 0x24, r24 ; 36
132: 84 b5 in r24, 0x24 ; 36
134: 81 60 ori r24, 0x01 ; 1
136: 84 bd out 0x24, r24 ; 36
138: 85 b5 in r24, 0x25 ; 37
13a: 82 60 ori r24, 0x02 ; 2
13c: 85 bd out 0x25, r24 ; 37
13e: 85 b5 in r24, 0x25 ; 37
140: 81 60 ori r24, 0x01 ; 1
142: 85 bd out 0x25, r24 ; 37
144: 80 91 6e 00 lds r24, 0x006E ; 0x80006e
148: 81 60 ori r24, 0x01 ; 1
14a: 80 93 6e 00 sts 0x006E, r24 ; 0x80006e
14e: 10 92 81 00 sts 0x0081, r1 ; 0x800081
152: 80 91 81 00 lds r24, 0x0081 ; 0x800081
156: 82 60 ori r24, 0x02 ; 2
158: 80 93 81 00 sts 0x0081, r24 ; 0x800081
15c: 80 91 81 00 lds r24, 0x0081 ; 0x800081
160: 81 60 ori r24, 0x01 ; 1
162: 80 93 81 00 sts 0x0081, r24 ; 0x800081
166: 80 91 80 00 lds r24, 0x0080 ; 0x800080
16a: 81 60 ori r24, 0x01 ; 1
16c: 80 93 80 00 sts 0x0080, r24 ; 0x800080
170: 80 91 b1 00 lds r24, 0x00B1 ; 0x8000b1
174: 84 60 ori r24, 0x04 ; 4
176: 80 93 b1 00 sts 0x00B1, r24 ; 0x8000b1
17a: 80 91 b0 00 lds r24, 0x00B0 ; 0x8000b0
17e: 81 60 ori r24, 0x01 ; 1
180: 80 93 b0 00 sts 0x00B0, r24 ; 0x8000b0
184: 80 91 7a 00 lds r24, 0x007A ; 0x80007a
188: 84 60 ori r24, 0x04 ; 4
18a: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a
18e: 80 91 7a 00 lds r24, 0x007A ; 0x80007a
192: 82 60 ori r24, 0x02 ; 2
194: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a
198: 80 91 7a 00 lds r24, 0x007A ; 0x80007a
19c: 81 60 ori r24, 0x01 ; 1
19e: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a
1a2: 80 91 7a 00 lds r24, 0x007A ; 0x80007a
1a6: 80 68 ori r24, 0x80 ; 128
1a8: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a
1ac: 10 92 c1 00 sts 0x00C1, r1 ; 0x8000c1
1b0: c0 e0 ldi r28, 0x00 ; 0
1b2: d0 e0 ldi r29, 0x00 ; 0
1b4: 20 97 sbiw r28, 0x00 ; 0
1b6: f1 f3 breq .-4 ; 0x1b4
1b8: 0e 94 00 00 call 0 ; 0x0
1bc: fb cf rjmp .-10 ; 0x1b4
1be: f8 94 cli
1c0: ff cf rjmp .-2 ; 0x1c0
Code: Alles auswählen
avr-objdump -S sketch_dec09a.ino.elf -m avr5 >/media/ramdisk/dis3.dump
Code: Alles auswählen
sketch_dec09a.ino.elf: file format elf32-avr
Disassembly of section .text:
00000000 <__vectors>:
0: 0c 94 34 00 jmp 0x68 ; 0x68 <__ctors_end>
4: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
8: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
10: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
14: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
18: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
1c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
20: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
24: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
28: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
2c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
30: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
34: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
38: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
3c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
40: 0c 94 4b 00 jmp 0x96 ; 0x96 <__vector_16>
44: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
48: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
4c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
50: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
54: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
58: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
5c: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
60: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
64: 0c 94 46 00 jmp 0x8c ; 0x8c <__bad_interrupt>
00000068 <__ctors_end>:
68: 11 24 eor r1, r1
6a: 1f be out 0x3f, r1 ; 63
6c: cf ef ldi r28, 0xFF ; 255
6e: d8 e0 ldi r29, 0x08 ; 8
70: de bf out 0x3e, r29 ; 62
72: cd bf out 0x3d, r28 ; 61
00000074 <__do_clear_bss>:
74: 21 e0 ldi r18, 0x01 ; 1
76: a0 e0 ldi r26, 0x00 ; 0
78: b1 e0 ldi r27, 0x01 ; 1
7a: 01 c0 rjmp .+2 ; 0x7e <.do_clear_bss_start>
0000007c <.do_clear_bss_loop>:
7c: 1d 92 st X+, r1
0000007e <.do_clear_bss_start>:
7e: a9 30 cpi r26, 0x09 ; 9
80: b2 07 cpc r27, r18
82: e1 f7 brne .-8 ; 0x7c <.do_clear_bss_loop>
84: 0e 94 95 00 call 0x12a ; 0x12a <main>
88: 0c 94 df 00 jmp 0x1be ; 0x1be <_exit>
0000008c <__bad_interrupt>:
8c: 0c 94 00 00 jmp 0 ; 0x0 <__vectors>
00000090 <_Z8addivariii>:
int addivari(int a, int b){
int c;
c = a + b;
return c;
}
90: 86 0f add r24, r22
92: 97 1f adc r25, r23
94: 08 95 ret
00000096 <__vector_16>:
#if defined(TIM0_OVF_vect)
ISR(TIM0_OVF_vect)
#else
ISR(TIMER0_OVF_vect)
#endif
{
96: 1f 92 push r1
98: 0f 92 push r0
9a: 0f b6 in r0, 0x3f ; 63
9c: 0f 92 push r0
9e: 11 24 eor r1, r1
a0: 2f 93 push r18
a2: 3f 93 push r19
a4: 8f 93 push r24
a6: 9f 93 push r25
a8: af 93 push r26
aa: bf 93 push r27
// copy these to local variables so they can be stored in registers
// (volatile variables must be read from memory on every access)
unsigned long m = timer0_millis;
ac: 80 91 05 01 lds r24, 0x0105 ; 0x800105 <timer0_millis>
b0: 90 91 06 01 lds r25, 0x0106 ; 0x800106 <timer0_millis+0x1>
b4: a0 91 07 01 lds r26, 0x0107 ; 0x800107 <timer0_millis+0x2>
b8: b0 91 08 01 lds r27, 0x0108 ; 0x800108 <timer0_millis+0x3>
unsigned char f = timer0_fract;
bc: 30 91 04 01 lds r19, 0x0104 ; 0x800104 <timer0_fract>
m += MILLIS_INC;
f += FRACT_INC;
c0: 23 e0 ldi r18, 0x03 ; 3
c2: 23 0f add r18, r19
if (f >= FRACT_MAX) {
c4: 2d 37 cpi r18, 0x7D ; 125
c6: 58 f5 brcc .+86 ; 0x11e <__vector_16+0x88>
// copy these to local variables so they can be stored in registers
// (volatile variables must be read from memory on every access)
unsigned long m = timer0_millis;
unsigned char f = timer0_fract;
m += MILLIS_INC;
c8: 01 96 adiw r24, 0x01 ; 1
ca: a1 1d adc r26, r1
cc: b1 1d adc r27, r1
if (f >= FRACT_MAX) {
f -= FRACT_MAX;
m += 1;
}
timer0_fract = f;
ce: 20 93 04 01 sts 0x0104, r18 ; 0x800104 <timer0_fract>
timer0_millis = m;
d2: 80 93 05 01 sts 0x0105, r24 ; 0x800105 <timer0_millis>
d6: 90 93 06 01 sts 0x0106, r25 ; 0x800106 <timer0_millis+0x1>
da: a0 93 07 01 sts 0x0107, r26 ; 0x800107 <timer0_millis+0x2>
de: b0 93 08 01 sts 0x0108, r27 ; 0x800108 <timer0_millis+0x3>
timer0_overflow_count++;
e2: 80 91 00 01 lds r24, 0x0100 ; 0x800100 <_edata>
e6: 90 91 01 01 lds r25, 0x0101 ; 0x800101 <_edata+0x1>
ea: a0 91 02 01 lds r26, 0x0102 ; 0x800102 <_edata+0x2>
ee: b0 91 03 01 lds r27, 0x0103 ; 0x800103 <_edata+0x3>
f2: 01 96 adiw r24, 0x01 ; 1
f4: a1 1d adc r26, r1
f6: b1 1d adc r27, r1
f8: 80 93 00 01 sts 0x0100, r24 ; 0x800100 <_edata>
fc: 90 93 01 01 sts 0x0101, r25 ; 0x800101 <_edata+0x1>
100: a0 93 02 01 sts 0x0102, r26 ; 0x800102 <_edata+0x2>
104: b0 93 03 01 sts 0x0103, r27 ; 0x800103 <_edata+0x3>
}
108: bf 91 pop r27
10a: af 91 pop r26
10c: 9f 91 pop r25
10e: 8f 91 pop r24
110: 3f 91 pop r19
112: 2f 91 pop r18
114: 0f 90 pop r0
116: 0f be out 0x3f, r0 ; 63
118: 0f 90 pop r0
11a: 1f 90 pop r1
11c: 18 95 reti
unsigned char f = timer0_fract;
m += MILLIS_INC;
f += FRACT_INC;
if (f >= FRACT_MAX) {
f -= FRACT_MAX;
11e: 26 e8 ldi r18, 0x86 ; 134
120: 23 0f add r18, r19
m += 1;
122: 02 96 adiw r24, 0x02 ; 2
124: a1 1d adc r26, r1
126: b1 1d adc r27, r1
128: d2 cf rjmp .-92 ; 0xce <__vector_16+0x38>
0000012a <main>:
void init()
{
// this needs to be called before setup() or some functions won't
// work there
sei();
12a: 78 94 sei
// on the ATmega168, timer 0 is also used for fast hardware pwm
// (using phase-correct PWM would mean that timer 0 overflowed half as often
// resulting in different millis() behavior on the ATmega8 and ATmega168)
#if defined(TCCR0A) && defined(WGM01)
sbi(TCCR0A, WGM01);
12c: 84 b5 in r24, 0x24 ; 36
12e: 82 60 ori r24, 0x02 ; 2
130: 84 bd out 0x24, r24 ; 36
sbi(TCCR0A, WGM00);
132: 84 b5 in r24, 0x24 ; 36
134: 81 60 ori r24, 0x01 ; 1
136: 84 bd out 0x24, r24 ; 36
// this combination is for the standard atmega8
sbi(TCCR0, CS01);
sbi(TCCR0, CS00);
#elif defined(TCCR0B) && defined(CS01) && defined(CS00)
// this combination is for the standard 168/328/1280/2560
sbi(TCCR0B, CS01);
138: 85 b5 in r24, 0x25 ; 37
13a: 82 60 ori r24, 0x02 ; 2
13c: 85 bd out 0x25, r24 ; 37
sbi(TCCR0B, CS00);
13e: 85 b5 in r24, 0x25 ; 37
140: 81 60 ori r24, 0x01 ; 1
142: 85 bd out 0x25, r24 ; 37
// enable timer 0 overflow interrupt
#if defined(TIMSK) && defined(TOIE0)
sbi(TIMSK, TOIE0);
#elif defined(TIMSK0) && defined(TOIE0)
sbi(TIMSK0, TOIE0);
144: 80 91 6e 00 lds r24, 0x006E ; 0x80006e <__TEXT_REGION_LENGTH__+0x7e006e>
148: 81 60 ori r24, 0x01 ; 1
14a: 80 93 6e 00 sts 0x006E, r24 ; 0x80006e <__TEXT_REGION_LENGTH__+0x7e006e>
// this is better for motors as it ensures an even waveform
// note, however, that fast pwm mode can achieve a frequency of up
// 8 MHz (with a 16 MHz clock) at 50% duty cycle
#if defined(TCCR1B) && defined(CS11) && defined(CS10)
TCCR1B = 0;
14e: 10 92 81 00 sts 0x0081, r1 ; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
// set timer 1 prescale factor to 64
sbi(TCCR1B, CS11);
152: 80 91 81 00 lds r24, 0x0081 ; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
156: 82 60 ori r24, 0x02 ; 2
158: 80 93 81 00 sts 0x0081, r24 ; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
#if F_CPU >= 8000000L
sbi(TCCR1B, CS10);
15c: 80 91 81 00 lds r24, 0x0081 ; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
160: 81 60 ori r24, 0x01 ; 1
162: 80 93 81 00 sts 0x0081, r24 ; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
sbi(TCCR1, CS10);
#endif
#endif
// put timer 1 in 8-bit phase correct pwm mode
#if defined(TCCR1A) && defined(WGM10)
sbi(TCCR1A, WGM10);
166: 80 91 80 00 lds r24, 0x0080 ; 0x800080 <__TEXT_REGION_LENGTH__+0x7e0080>
16a: 81 60 ori r24, 0x01 ; 1
16c: 80 93 80 00 sts 0x0080, r24 ; 0x800080 <__TEXT_REGION_LENGTH__+0x7e0080>
// set timer 2 prescale factor to 64
#if defined(TCCR2) && defined(CS22)
sbi(TCCR2, CS22);
#elif defined(TCCR2B) && defined(CS22)
sbi(TCCR2B, CS22);
170: 80 91 b1 00 lds r24, 0x00B1 ; 0x8000b1 <__TEXT_REGION_LENGTH__+0x7e00b1>
174: 84 60 ori r24, 0x04 ; 4
176: 80 93 b1 00 sts 0x00B1, r24 ; 0x8000b1 <__TEXT_REGION_LENGTH__+0x7e00b1>
// configure timer 2 for phase correct pwm (8-bit)
#if defined(TCCR2) && defined(WGM20)
sbi(TCCR2, WGM20);
#elif defined(TCCR2A) && defined(WGM20)
sbi(TCCR2A, WGM20);
17a: 80 91 b0 00 lds r24, 0x00B0 ; 0x8000b0 <__TEXT_REGION_LENGTH__+0x7e00b0>
17e: 81 60 ori r24, 0x01 ; 1
180: 80 93 b0 00 sts 0x00B0, r24 ; 0x8000b0 <__TEXT_REGION_LENGTH__+0x7e00b0>
#endif
#if defined(ADCSRA)
// set a2d prescaler so we are inside the desired 50-200 KHz range.
#if F_CPU >= 16000000 // 16 MHz / 128 = 125 KHz
sbi(ADCSRA, ADPS2);
184: 80 91 7a 00 lds r24, 0x007A ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
188: 84 60 ori r24, 0x04 ; 4
18a: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
sbi(ADCSRA, ADPS1);
18e: 80 91 7a 00 lds r24, 0x007A ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
192: 82 60 ori r24, 0x02 ; 2
194: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
sbi(ADCSRA, ADPS0);
198: 80 91 7a 00 lds r24, 0x007A ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
19c: 81 60 ori r24, 0x01 ; 1
19e: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
cbi(ADCSRA, ADPS2);
cbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
#endif
// enable a2d conversions
sbi(ADCSRA, ADEN);
1a2: 80 91 7a 00 lds r24, 0x007A ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
1a6: 80 68 ori r24, 0x80 ; 128
1a8: 80 93 7a 00 sts 0x007A, r24 ; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
// here so they can be used as normal digital i/o; they will be
// reconnected in Serial.begin()
#if defined(UCSRB)
UCSRB = 0;
#elif defined(UCSR0B)
UCSR0B = 0;
1ac: 10 92 c1 00 sts 0x00C1, r1 ; 0x8000c1 <__TEXT_REGION_LENGTH__+0x7e00c1>
setup();
for (;;) {
loop();
if (serialEventRun) serialEventRun();
1b0: c0 e0 ldi r28, 0x00 ; 0
1b2: d0 e0 ldi r29, 0x00 ; 0
1b4: 20 97 sbiw r28, 0x00 ; 0
1b6: f1 f3 breq .-4 ; 0x1b4 <main+0x8a>
1b8: 0e 94 00 00 call 0 ; 0x0 <__vectors>
1bc: fb cf rjmp .-10 ; 0x1b4 <main+0x8a>
000001be <_exit>:
1be: f8 94 cli
000001c0 <__stop_program>:
1c0: ff cf rjmp .-2 ; 0x1c0 <__stop_program>
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Nicht mit genau diesen, aber mit vergleichbaren. Das geht ziemlich unkompliziert mit den entsprechenden Libraries. Verdrahten, aufrufen, fertig.Später Gast hat geschrieben: ↑Fr 29. Nov 2019, 19:37
Die Visualisierung des Lautstärkepuffers ist blöd mit den Zahlen, da such ich noch was anderes, Vllt sone Dot-Matrix, da hab ich nur noch keine mit Max7219 und RGB LED als Paket gefunden. Hat Jemand schon Erfahrungen mit diesen einzeln ansteuerbaren LedStrips?
Ich würd da gerne 10-er Blocks runterschnippeln und dann damit den Puffer in grün(+) und rot(-) anzeigen. Geht das?
Was man aber beachten muss ist, dass die sehr empfindlich sind, was die Stromversorgung und den Pegel am Input angeht. Sollte die Stromversorgung aus sein, der Input aber auf High gezogen werden, gehen die sofort kaputt. Schützen kann man die, indem man in die Datenleitung einen 330 Ohm-Widerstand einbaut und zwei Schottky-Dioden zwischen Dateneingang und Plusleitung beziehungsweise Minusleitung lötet. So, dass die von Minus nach Dateneingang nach Plus leitend wären. Wenn man das dann auch noch direkt an den Streifen lötet, sollte eigentlich nichts mehr passieren.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Echt jetzt? Habs schon geordert. Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.Weisskeinen hat geschrieben: ↑Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
Okay, danke. da hätt ich sicher n paar gehimmelt sonst.Was man aber beachten muss ist, dass die sehr empfindlich sind, was die Stromversorgung und den Pegel am Input angeht.
[...] sollte eigentlich nichts mehr passieren.
Re: Der AVR-/ARDUINO-Faden
Warum das eine kompilierbar ist (vrmtl mit Warnung) und das andere nicht, ist darin zu sehen, ob die Konvertierung explizit oder implizit erfolgt.
Serial.println ist eine überladene Funktion, und kann mehrere Typen annehmen (mindestens char *,int, float), wo es auch noch unterschiedliche Dinge tut. Der Compiler hat hier keine eindeutig valide Konvertierung zur Verfügung.
Im 2. Fall ist die Anweisung klar: Nimm den Pointer, pack ihn in einen unsigned long int (Diese Konvertierung ist zulässig, gibt aber normalerweise eine Warnung, die vrmtl von der Arduino-IDE hinter weiterem Text vergraben wird), zeige dann den unsigned long int an.
Serial.println((unsigned long int)millis);
sollte das gleiche tun.
Serial.println ist eine überladene Funktion, und kann mehrere Typen annehmen (mindestens char *,int, float), wo es auch noch unterschiedliche Dinge tut. Der Compiler hat hier keine eindeutig valide Konvertierung zur Verfügung.
Im 2. Fall ist die Anweisung klar: Nimm den Pointer, pack ihn in einen unsigned long int (Diese Konvertierung ist zulässig, gibt aber normalerweise eine Warnung, die vrmtl von der Arduino-IDE hinter weiterem Text vergraben wird), zeige dann den unsigned long int an.
Serial.println((unsigned long int)millis);
sollte das gleiche tun.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Äh, ja, vergleichbar insofern, dass meine auch diese WS2812B-LEDs drauf haben, aber in größerem Abstand und bei jemand anderem gekauft. Sonst nichts. Und ja, die kann man nach jeder LED abschneiden. Für größere Installationen sind die halt deshalb doof, weil die einzelne LED voll an 60mA braucht, bei 100 Stück muss man schon 6A bereit stellen u.s.w.. Es gibt wohl mittlerweile auch hochwertigere (!) Klone...Später Gast hat geschrieben: ↑Di 10. Dez 2019, 00:10Echt jetzt? Habs schon geordert. Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.Weisskeinen hat geschrieben: ↑Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Achso puh, dann hab ich dich nur falsch verstanden. Mit "ziemlich ähnlichen" dachte ich, da bräuchte ich was anderes...
Hmm ja Stromverbrauch. mal schauen, ob ich das überhaupt voll aufdrehen muss, bei den Siebensegmentanzeigen reicht ja auch Stufe 1 oder 2 von 16.
Hmm ja Stromverbrauch. mal schauen, ob ich das überhaupt voll aufdrehen muss, bei den Siebensegmentanzeigen reicht ja auch Stufe 1 oder 2 von 16.
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Guten morgen zusammen
ich hab einen Code in Arduinisch zusammengebastelt und ste ein bisschen auf dem Schlauch.
Achja, Ich bin schon nicht mehr ganz neu ("Arduinoforum") und daher schreib ich da nix.
in meinem Code hab ich einen Zähler der nicht tut. auch umbenennen und auf einem anderen Rechner Compilern
hat nichts gebracht.
ich hab den jetzt mal mit "dieser_geht_nicht" bennant. kann sich das villeicht mal einer anschauen ob der Fehler auch so
auftritt oder mir erklären warum das nicht geht?
achja Code[/code]
danke fürs anschauen und ev. Antwort
frickelfred
man kann das auch anders und besser machen, try and error eben
ich hab einen Code in Arduinisch zusammengebastelt und ste ein bisschen auf dem Schlauch.
Achja, Ich bin schon nicht mehr ganz neu ("Arduinoforum") und daher schreib ich da nix.
in meinem Code hab ich einen Zähler der nicht tut. auch umbenennen und auf einem anderen Rechner Compilern
hat nichts gebracht.
ich hab den jetzt mal mit "dieser_geht_nicht" bennant. kann sich das villeicht mal einer anschauen ob der Fehler auch so
auftritt oder mir erklären warum das nicht geht?
achja Code
Code: Alles auswählen
[code]
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
#include <EEPROM.h>
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
#define CE_PIN 8
#define CSN_PIN 9
RF24 radio(CE_PIN, CSN_PIN); // Create a Radio
// Set the LCD address to 0x27 for a 16 chars and 2 line display
LiquidCrystal_I2C lcd(0x27, 16, 2);
// -------------------const--------------------------
const char m_01[] PROGMEM = " Version v6 "; // Maximal 16 Zeichen
const char m_02[] PROGMEM = "DMT ------------";
const char m_03[] PROGMEM = " Meldung 2 ";
const char m_04[] PROGMEM = " Meldung 3 ";
const char m_05[] PROGMEM = " Meldung 4 ";
const char m_06[] PROGMEM = " Meldung 5 ";
const char m_07[] PROGMEM = " ";
const char m_08[] PROGMEM = " ";
const char m_09[] PROGMEM = " Reset druecken ";
const char* const mymenue[] PROGMEM = {m_01, m_02, m_03, m_04, m_05, m_06, m_07, m_08, m_09};
char b1menue[18];
const char m_11[] PROGMEM = "DMT kV "; // Maximal 8 Zeichen
const char m_12[] PROGMEM = " Kanal : ";
const char m_13[] PROGMEM = " MW 2 : ";
const char m_14[] PROGMEM = " MW 3 : ";
const char m_15[] PROGMEM = " MW 4 : ";
const char m_16[] PROGMEM = " MW 5 : ";
const char m_17[] PROGMEM = "# ";
const char m_18[] PROGMEM = " Save ";
const char* const mymenue1[] PROGMEM = {m_11, m_12, m_13, m_14, m_15, m_16, m_17, m_18};
char b2menue[10];
const char m_21[] PROGMEM = "FE 12/19 "; // Maximal 8 Zeichen
const char m_22[] PROGMEM = "Speed : ";
const char m_23[] PROGMEM = "Strom : ";
const char m_24[] PROGMEM = "U-Batt : ";
const char m_25[] PROGMEM = "U-Akku : ";
const char m_26[] PROGMEM = "Comm : ";
const char m_27[] PROGMEM = " --- : ";
//const char m_26[] PROGMEM = " ## ";
//const char m_27[] PROGMEM = " # ";
const char* const mymenue3[] PROGMEM = {m_21, m_22, m_23, m_24, m_25, m_26, m_27};
char b3menue[9];
// --------------------var---------------------------
const byte slaveAddress[5] = {'D', 'M', 'T', 'K', 'V'};
const long lcd_on = 30000 ; //15000;
const int tol = 25;
const int m_interval = 3000;
const int t_delay = 50; // Tasten entprellzeit
const int t_out = 30000;
unsigned long txIntervalMillis = 15000; // send once per second
// nrf24l01 variablen
//char dataToSend[10] = "Message 0";
int dataToSend[10] = { -1, -12, -3, -1, -1, -1, -1, -1, -1, -1};
char txNum = '0';
int ackData[4] = { -1, -1, -1, -1}; // to hold the two values coming from the slave
bool newData = false;
unsigned long c_millis;
unsigned long p_millis;
unsigned long m_millis;
unsigned long t_e_millis;
unsigned long t_up_millis;
unsigned long t_dwn_millis;
unsigned long t_out_millis;
byte x_var[8];
float b_var[8] = {0.0, 0.2, 0.3, 123.4, 0.5, 0.6, 0.7};
char* wert[] = {"High ","OK ","Low "};
int taste = 0;
bool taste_e = 0;
bool taste_up = 0;
bool taste_dwn = 0;
bool old_e;
bool old_up;
bool old_dwn;
bool t_e_imp;
bool t_up_imp;
bool t_dwn_imp;
byte mset = 0;
byte dummy1;
byte s_menue;
byte dummy2;
byte m_i;
byte mm_i;
byte dieser_geht_nicht;
//------------------------------------setup---------------------
void setup() {
// put your setup code here, to run once:
lcd.begin();
lcd.backlight();
Serial.begin(19200);
for (byte i = 0; i < 8; i++) {
x_var[i] = EEPROM.read(i);
}
radio.begin();
radio.setDataRate( RF24_250KBPS );
radio.enableAckPayload();
radio.setRetries(3, 5); // delay, count
radio.openWritingPipe(slaveAddress);
strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[0])));
lcd.setCursor(0, 0);
lcd.print(b1menue);
delay(500);
readTaste();
if (taste_e) mset = 1; // Setup_Menue aufrufen
dummy1 = 10;
dummy2 = 20;
//Serial.println(freeRam());
}
void readTaste() {
taste = analogRead(A3); // Tasten einlesen über Analog
taste_e = 0; taste_up = 0; taste_dwn = 0;
if (taste >= 0 & taste <= (0 + tol)) taste_e = 1;
if (taste >= 550 & taste <= (550 + tol)) taste_dwn = 1;
if (taste >= 920 & taste <= (920 + tol)) taste_up = 1;
}
//--------------------------------------------------------------------------
void showData() {
if (newData == true) {
Serial.print(" Acknowledge data ");
Serial.print(ackData[0]);
Serial.print(", ");
Serial.print(ackData[1]);
Serial.print(", ");
Serial.print(ackData[2]);
Serial.print(", ");
Serial.print(ackData[3]);
Serial.println();
newData = false;
}
}
//----------------------loop-----------------------
void loop() {
// put your main code here, to run repeatedly:
c_millis = millis();
// ---------------Tasten auswerten-----------------
readTaste();
if (taste_e) { // Taste enable
if (!old_e & (c_millis - t_e_millis >= t_delay)) {
old_e = 1;
t_e_imp = 1;
Serial.println("taste E ");
t_out_millis = c_millis;
} else {
t_e_imp = 0;
}
} else {
t_e_millis = c_millis;
old_e = 0;
t_e_imp = 0;
}
//if (t_e_imp) Serial.println("imp E ");
if (taste_up) { // Taste up
if (!old_up & (c_millis - t_up_millis >= t_delay)) {
old_up = 1;
t_up_imp = 1;
Serial.println(taste);
t_out_millis = c_millis;
Serial.println("taste UP ");
} else {
t_up_imp = 0;
}
} else {
t_up_millis = c_millis;
old_up = 0;
t_up_imp = 0;
} //ende t_up
//if (t_up_imp) Serial.println("imp UP ");
if (taste_dwn) { // Taste down
if (!old_dwn & (c_millis - t_dwn_millis >= t_delay)) {
old_dwn = 1;
t_dwn_imp = 1;
t_out_millis = c_millis;
Serial.println("taste DWN ");
} else {
t_dwn_imp = 0;
}
} else {
t_dwn_millis = c_millis;
old_dwn = 0;
t_dwn_imp = 0;
} // ende t_dwn
//if (t_dwn_imp) Serial.println("imp DWN ");
// ----------------Einstellmenue---------------------
//xxxxxxxx
if ( mset == 1 & t_e_imp & mm_i == 7) { // setup verlassen
for (byte i = 0; i < 8; i++) {
EEPROM.write( i, x_var[i] );
}
mm_i = 0;
mset = 2;
strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[1])));
lcd.setCursor(0, 0);
lcd.print(b1menue);
strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[8])));
lcd.setCursor(0, 1);
lcd.print(b1menue);
}
if (mset == 1 & t_up_imp) {
if ( s_menue == 0) { // taste incr
x_var[mm_i] = x_var[mm_i] + 1;
Serial.print(" s_m : ");
Serial.println(s_menue);
} else {
mm_i++;
if (mm_i >= 8) mm_i = 1;
}
}
if (mset == 1 & t_dwn_imp) {
if ( s_menue == 0) {
x_var[mm_i] = x_var[mm_i] - 1;
} else {
if (mm_i >= 1) mm_i--;
if (mm_i <= 1) mm_i = 7;
}
}
if (mset == 1 & t_e_imp ) {
if ( s_menue == 1 ) { // taste e
// dummy2 = dummy2 - 1;
s_menue = 0;
// dummy1 = dummy1 + 1;
if ( s_menue >= 2) s_menue = 0;
} else {
s_menue = 1;
}
}
if ( mset == 1) {
lcd.setCursor(0, 0);
//Serial.print(" XX1 ");
lcd.print(" Setup ");
lcd.setCursor(0, 1);
strcpy_P(b2menue, (char*)pgm_read_word(&(mymenue1[mm_i])));
lcd.print(b2menue);
if (mm_i >= 1 & mm_i <= 5 ) {
if (s_menue == 0) {
lcd.write(0x23);
} else {
lcd.write(0x20);
}
lcd.print(x_var[mm_i]);
} else {
lcd.print(" ");
}
}
if (mset == 0 ) { // Normalbetrieb
//-------------------Anzeige rollen----------------
if ( c_millis - m_millis >= m_interval ) {
m_millis = c_millis;
//Serial.print("abc ");Serial.println(m_i);
dummy1++;
dieser_geht_nicht++; //m_i++;
Serial.print("dieser_geht_nicht : "); Serial.println(dieser_geht_nicht);
Serial.print("dummy: "); Serial.println(dummy1);
if ( dummy1 >= 7) {
dummy1 = 0;
Serial.print("xyz ");
}
lcd.setCursor(0, 0);
strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[1])));
lcd.print(b1menue);
lcd.setCursor(0, 1);
strcpy_P(b3menue, (char*)pgm_read_word(&(mymenue3[dummy1])));
lcd.print(b3menue);
if (dummy1 >= 1 & dummy1 <= 2) {
lcd.print(b_var[dummy1]);
lcd.print(" ");
} else if (dummy1 >= 3 & dummy1 <= 5) {
lcd.print(wert[1]);
}else {
lcd.print(" ");
}
//m_i++;
}
}
//currentMillis = millis();
if (c_millis - p_millis >= txIntervalMillis) {
send();
p_millis = c_millis;
}
} //ende loop
// ---------------------------------------------------------------
void send() {
bool rslt;
radio.stopListening();
rslt = radio.write( &dataToSend, sizeof(dataToSend) );
// Always use sizeof() as it gives the size as the number of bytes.
// For example if dataToSend was an int sizeof() would correctly return 2
radio.startListening();
Serial.print("Data Sent ");
for (byte i = 0; i < 9; i++ ) {
Serial.print(dataToSend[i]);
Serial.print(", ");
}
if (rslt) {
if ( radio.isAckPayloadAvailable() ) {
radio.read(&ackData, sizeof(ackData));
newData = true;
} else {
Serial.println(" Acknowledge but no data ");
}
showData();
//updateMessage();
} else {
Serial.println(" Tx fialed");
}
}
//--------------------------------------------------------------------------
int freeRam () {
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
danke fürs anschauen und ev. Antwort
frickelfred
man kann das auch anders und besser machen, try and error eben
Re: Der AVR-/ARDUINO-Faden
nicht initialisiert würd ich sagen.
byte dieser_geht_nicht=0;
das gilt für die anderen auch
byte dieser_geht_nicht=0;
das gilt für die anderen auch
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
dann musst du in der Setup initialisieren/definieren.
die variable gibt's, aber der wert ist unklar.
also "Was?++" geht dann halt nicht.
(nehme ich an)
Code: Alles auswählen
byte dieser_geht_nicht;
//------------------------------------setup---------------------
void setup() {
dieser_geht_nicht=0;
// put your setup code here, to run once:
also "Was?++" geht dann halt nicht.
(nehme ich an)
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Undefiniert gibt's letztlich ja eigentlich nicht, da steht halt eventuell irgend ein Wert drin, der hoch gezählt werden soll. Was heißt denn "geht nicht"? Wird nicht hoch gezählt? Programm läuft gar nicht? Seltsame Dinge passieren? Andere Variablen bekommen falsche Werte?
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Gegenfrage
meine Ersatzvarialble "dummy1" geht und macht das was "dieser_geht_nicht" tun soll?
meine Ersatzvarialble "dummy1" geht und macht das was "dieser_geht_nicht" tun soll?
Re: Der AVR-/ARDUINO-Faden
herrje,
dummy1 definierst du in der setup.
probiers doch einfach aus.
wenn alle variablen definiert sind, ist ihr zustand klar ohne sich in den untiefen des compilers auskennen zu zu müßen.
dummy1 definierst du in der setup.
Code: Alles auswählen
if (taste_e) mset = 1; // Setup_Menue aufrufen
dummy1 = 10;
dummy2 = 20;
//Serial.println(freeRam());
wenn alle variablen definiert sind, ist ihr zustand klar ohne sich in den untiefen des compilers auskennen zu zu müßen.
Re: Der AVR-/ARDUINO-Faden
muss theoretisch nicht im Setup sein.
Kannst du - wie du es ja bei anderen Variablen (z.B.: mset) machst, auch im define machen:
Kannst du - wie du es ja bei anderen Variablen (z.B.: mset) machst, auch im define machen:
Code: Alles auswählen
byte mset = 0;
byte dummy1;
byte s_menue;
byte dummy2;
byte m_i;
byte mm_i;
byte dieser_geht_nicht = 0;
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
ich habe es jetzt nochmal Probiert.
"dieser_geht...." mit 0 initialisiert - gleiches verhalten wie vor
"dieser_geht...." mit 10 initialisiert - der Zähler zählt, aber dafür "dummy1" nicht mehr.
"dummy1" mit 10 initialisiert und beide laufen
Den Zusammenhang versteh ich nicht, und die Glaskugel ist in Revision
frickelfred
"dieser_geht...." mit 0 initialisiert - gleiches verhalten wie vor
"dieser_geht...." mit 10 initialisiert - der Zähler zählt, aber dafür "dummy1" nicht mehr.
"dummy1" mit 10 initialisiert und beide laufen
Den Zusammenhang versteh ich nicht, und die Glaskugel ist in Revision
frickelfred
Re: Der AVR-/ARDUINO-Faden
OK.
Verzeih wenn das jetzt brutal ist - aber ich hab so einen mords schnupfen und kann nimmer denken.
Wenn du das nicht verstehst, dann solltest du mal bei arduino "blink" - Example beginnen und die Sprache lernen, sonst wirst du so ein anspruchsvolleres Programm nie (sauber) zum laufen bekommen.
Verzeih wenn das jetzt brutal ist - aber ich hab so einen mords schnupfen und kann nimmer denken.
Wenn du das nicht verstehst, dann solltest du mal bei arduino "blink" - Example beginnen und die Sprache lernen, sonst wirst du so ein anspruchsvolleres Programm nie (sauber) zum laufen bekommen.
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Am Anfang sah mein "Programm " so wie in dem Beispiel aus. Trotzdem DankeSir_Death hat geschrieben: ↑Do 12. Dez 2019, 17:51 OK.
Verzeih wenn das jetzt brutal ist - aber ich hab so einen mords schnupfen und kann nimmer denken.
Wenn du das nicht verstehst, dann solltest du mal bei arduino "blink" - Example beginnen und die Sprache lernen, sonst wirst du so ein anspruchsvolleres Programm nie (sauber) zum laufen bekommen.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Wie sieht's denn mit der Speicherbelegung aus? Ich hatte so ein Verhalten mal, als sich Heap und Stack in die Quere gekommen sind.
Manchmal machen die Compiler aber auch Blödsinn und man muss an einer bestimmten Stelle was umformulieren, damit's klappt. Wenn man dann größere Änderungen am Programm macht, geht das plötzlich wieder, wie zu Beginn formuliert. Dafür ist die Assembler-Ausgabe ganz hilfreich...
Manchmal machen die Compiler aber auch Blödsinn und man muss an einer bestimmten Stelle was umformulieren, damit's klappt. Wenn man dann größere Änderungen am Programm macht, geht das plötzlich wieder, wie zu Beginn formuliert. Dafür ist die Assembler-Ausgabe ganz hilfreich...
Re: Der AVR-/ARDUINO-Faden
ich spiel grad rum mit einem MAP Sensor + UNO.
folgender code:
gibt mir:
830 815 0 839 wenn ich am sensor sauge:
446 439 0 448
das pins die in der luft hängen dem Sensorwert folgen kann ich nachvollziehen.
soweit alles gut.
ich hätte aber gern nur 8bit, das aber subito.
hab mir daher aus dem Netz was zusammengeklaubt (man solle den ADC Free Running mode benutzen):
das liefert in ruhe:
198 207 205 31
wenn ich sauge:
115 115 113 0
Da passt doch nix zusammen? also reihenfolge und betrag scheinen nicht zu stimmen.
Hab versucht zu recherchieren und zu verstehn, komm aber nicht weiter
folgender code:
Code: Alles auswählen
void setup() {
Serial.begin(9600);
}
void loop() {
Serial.print(analogRead(A0));
Serial.print("\t");
Serial.print(analogRead(A1));
Serial.print("\t");
Serial.print(analogRead(A2)); //gnd
Serial.print("\t");
Serial.println(analogRead(A3));//sensor
}
830 815 0 839 wenn ich am sensor sauge:
446 439 0 448
das pins die in der luft hängen dem Sensorwert folgen kann ich nachvollziehen.
soweit alles gut.
ich hätte aber gern nur 8bit, das aber subito.
hab mir daher aus dem Netz was zusammengeklaubt (man solle den ADC Free Running mode benutzen):
Code: Alles auswählen
#include "Arduino.h"
int numSamples = 0;
long t, t0;
volatile uint8_t ADCvalue;
volatile uint8_t z1;
volatile uint8_t z2;
volatile uint8_t z3;
volatile uint8_t z4;
void setup() {
Serial.begin(9600);
ADCSRA = 0; // clear ADCSRA register
ADCSRB = 0; // clear ADCSRB register
ADMUX |= (0 & 0x07); // set A0 analog input pin
ADMUX |= (1 << REFS0); // set reference voltage
ADMUX |= (1 << ADLAR); // left align ADC value to 8 bits from ADCH register
// sampling rate is [ADC clock] / [prescaler] / [conversion clock cycles]
// for Arduino Uno ADC clock is 16 MHz and a conversion takes 13 clock cycles
//ADCSRA |= (1 << ADPS2) | (1 << ADPS0); // 32 prescaler for 38.5 KHz
ADCSRA |= (1 << ADPS2); // 16 prescaler for 76.9 KHz
//ADCSRA |= (1 << ADPS1) | (1 << ADPS0); // 8 prescaler for 153.8 KHz
ADCSRA |= (1 << ADATE); // enable auto trigger
ADCSRA |= (1 << ADIE); // enable interrupts when measurement complete
ADCSRA |= (1 << ADEN); // enable ADC
ADCSRA |= (1 << ADSC); // start ADC measurements
}
ISR(ADC_vect) {
uint8_t tmp; // temp register for storage of misc data
tmp = ADMUX; // read the value of ADMUX register
tmp &= 0x0F; // AND the first 4 bits (value of ADC pin being used)
ADCvalue = ADCH; // read the sensor value
if (tmp == 0) {
z1 = ADCvalue; // put ADCvalue into whatever register you use for ADC0 sensor
ADMUX++; // add 1 to ADMUX to go to the next sensor
} else if (tmp == 1) {
z2 = ADCvalue; // put ADCvalue into whatever register you use for ADC1 sensor
ADMUX++; // add 1 to ADMUX to go to the next sensor
} else if (tmp == 2) {
z3 = ADCvalue; // put ADCvalue into whatever register you use for ADC1 sensor
ADMUX++; // add 1 to ADMUX to go to the next sensor
} else if (tmp == 3) {
z4 = ADCvalue; // put ADCvalue into whatever register you use for ADC2 sensor
ADMUX &= 0xF8; // clear the last 4 bits to reset the mux to ADC0
}
numSamples++;
}
void loop() {
if (numSamples >= 4) {
// Serial.print((char)z1);
// Serial.print((char)z2);
// Serial.print((char)z3);
// Serial.print((char)z4);
Serial.print(z1);
Serial.print("\t");
Serial.print(z2);
Serial.print("\t");
Serial.print(z3);
Serial.print("\t");
Serial.println(z4);
numSamples = 0;
}
// Serial.print((char)z4);
}
198 207 205 31
wenn ich sauge:
115 115 113 0
Da passt doch nix zusammen? also reihenfolge und betrag scheinen nicht zu stimmen.
Hab versucht zu recherchieren und zu verstehn, komm aber nicht weiter
Re: Der AVR-/ARDUINO-Faden
Der if/else Block ohne endbedingung ist schon mal eine blöde idee. -> geändert. löst die probleme aber nicht.
verkleinern der samplerate zieht zumindest schon mal den letzen kanal auf null. (209 206 205 0 )
ich arbeite dran.
edit:
A0 bis A2 auf Gnd gelegt, der Sensor liegt auf A3.
liefert mir den Sensorwert? nun gut, die anderen geben 0 aus, bei 38.5 KHz Samplerate.
Mit 76.9 KHz klappts nicht, 1 kanal wandert mit dem Sensorwert mit (196 32 0 0 )
nochmal edit:
hab gelesen analogRead() wäre blöd, freerunning mode wäre besser.
hab die mal spasseshalber angepasst (ADLAR und nur das high byte ausgeben), und es läuft (45-50kB/s)
So schaize kanns also nicht sein was die da machen.
verkleinern der samplerate zieht zumindest schon mal den letzen kanal auf null. (209 206 205 0 )
Code: Alles auswählen
ADCSRA |= (1 << ADPS2) | (1 << ADPS0); // 32 prescaler for 38.5 KHz
//ADCSRA |= (1 << ADPS2); // 16 prescaler for 76.9 KHz
//ADCSRA |= (1 << ADPS1) | (1 << ADPS0); // 8 prescaler for 153.8 KHz
edit:
A0 bis A2 auf Gnd gelegt, der Sensor liegt auf A3.
Code: Alles auswählen
Serial.print(analogRead(A0));
Mit 76.9 KHz klappts nicht, 1 kanal wandert mit dem Sensorwert mit (196 32 0 0 )
nochmal edit:
hab gelesen analogRead() wäre blöd, freerunning mode wäre besser.
hab die mal spasseshalber angepasst (ADLAR und nur das high byte ausgeben), und es läuft (45-50kB/s)
So schaize kanns also nicht sein was die da machen.
Code: Alles auswählen
byte analogRead8(uint8_t pin)
{
uint8_t low, high;
#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
#if defined(ADCSRB) && defined(MUX5)
// the MUX5 bit of ADCSRB selects whether we're reading from channels
// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits). this also sets ADLAR (left-adjust result)
// to 0 (the default).
#if defined(ADMUX)
#if defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
ADMUX = (analog_reference << 4) | (pin & 0x07);
ADMUX |= (1 << ADLAR); // left align ADC value to 8 bits from ADCH register
#else
ADMUX = (analog_reference << 6) | (pin & 0x07);
ADMUX |= (1 << ADLAR); // left align ADC value to 8 bits from ADCH register
#endif
#endif
// without a delay, we seem to read from the wrong channel
//delay(1);
#if defined(ADCSRA) && defined(ADCL)
// start the conversion
sbi(ADCSRA, ADSC);
// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));
// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read. reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low = ADCL;
high = ADCH;
#else
// we dont have an ADC, return 0
low = 0;
high = 0;
#endif
// combine the two bytes
// return (high << 8) | low;
return high;
}
Re: Der AVR-/ARDUINO-Faden
Ich hätte mal ne Frage an die Alteingesessenen AVR'ler hier.
Es geht um ein Timingkritisches Projekt mit einem der neuen ATTinys. Es soll das alte, Analoge D54 Steuersignal eines Strand Lightuing Lichtpults aufbereitet werden und von einem uC zu DMX übersetzt werden. Eine Schaltung, die den Controller mit Interrupts auf das Sync Signal füttert und den ADC mit einem gescheiten Pegel beschickt besteht, und funktioniert. Jetzt muss "nur" noch die Firmware programmiert werden. Dort stellt sich mir die Frage, C oder Assembler? Ersteres hat natürlich viele Vorteile, u.A. auch fertige Libs für DMX etc, in ASM müsste ich das mir selbst herbasteln, dafür ist ASM hardwarenäher und somit schneller. Die kürzesten Pulse sind die Sync Pulse mit 8uS, die in als Interrupt in den Controller gehen. Das ganze Timing Diagram gibts hier https://upload.wikimedia.org/wikipedia/en/e/eb/D54.png. Jetzt ist die Frage, womit ist das besser zu lösen? Ist C dafür schnell genug?
Danke für die Hilfe!
Es geht um ein Timingkritisches Projekt mit einem der neuen ATTinys. Es soll das alte, Analoge D54 Steuersignal eines Strand Lightuing Lichtpults aufbereitet werden und von einem uC zu DMX übersetzt werden. Eine Schaltung, die den Controller mit Interrupts auf das Sync Signal füttert und den ADC mit einem gescheiten Pegel beschickt besteht, und funktioniert. Jetzt muss "nur" noch die Firmware programmiert werden. Dort stellt sich mir die Frage, C oder Assembler? Ersteres hat natürlich viele Vorteile, u.A. auch fertige Libs für DMX etc, in ASM müsste ich das mir selbst herbasteln, dafür ist ASM hardwarenäher und somit schneller. Die kürzesten Pulse sind die Sync Pulse mit 8uS, die in als Interrupt in den Controller gehen. Das ganze Timing Diagram gibts hier https://upload.wikimedia.org/wikipedia/en/e/eb/D54.png. Jetzt ist die Frage, womit ist das besser zu lösen? Ist C dafür schnell genug?
Danke für die Hilfe!
Re: Der AVR-/ARDUINO-Faden
C auf jeden Fall wenn Du jetzt nicht gerade der Assembler Guru bist. Man kann ja immer noch etwas Inline Assembler einstreuen. Auch wenn das wahrscheinlich nicht nötig sein wird.
Re: Der AVR-/ARDUINO-Faden
Notfalls gibt es sicher auch noch die Möglichkeit, aus einem ASM-Stückchen eine C-Library zu bauen. Dazu wäre zwar ein Studium des Calling-Interfaces notwendig, aber damit könntest du dann beide Sprachen kombinieren.