Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
Schneller Optokoppler klingt nach einem Job für 6N137. Bis 10 MHz und gleich mit schönem logik Level Ausgang.
Re: Der AVR-/ARDUINO-Faden
Nun mehr als 10kHz erwarte ich da nicht
Ja ist ja im Auto
Re: Der AVR-/ARDUINO-Faden
@Fritzler: ich bastel gerade mit deiner bme280 lib auf einem mega8 herum (war grad da). Ist das normal, dass die Lib mit avr-gcc und -Os knapp 5 kb fett wird? Genaue Versionen von gcc und libc kann ich mirgen nachreichen, der PC is nur grad schon aus.
Ich hatte vor, deine Lib, ein 1wire DS1820 Code (900 Byte) von peda (Trollnest Forum) und yaMBSiavr (2kb) zu verheiraten.
Momentan kann ich entweder 1wire + BME + einfache Textausgabe auf Uart oder 1 wire und Modbus zusammenpacken. Für alle 3 reicht der Platz nicht aus...
Kann man da nich irgendwo abspecken? Gut, nächste Woche habe ich dann ein paar Ardu Mini pro (Mega328) hier, da wärs egal. Aber mich treibt es ein wenig um, dass das nicht da rein passen soll
Ich hatte vor, deine Lib, ein 1wire DS1820 Code (900 Byte) von peda (Trollnest Forum) und yaMBSiavr (2kb) zu verheiraten.
Momentan kann ich entweder 1wire + BME + einfache Textausgabe auf Uart oder 1 wire und Modbus zusammenpacken. Für alle 3 reicht der Platz nicht aus...
Kann man da nich irgendwo abspecken? Gut, nächste Woche habe ich dann ein paar Ardu Mini pro (Mega328) hier, da wärs egal. Aber mich treibt es ein wenig um, dass das nicht da rein passen soll
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Die printfs haste schon verbannt?
Ansonsten sind die 32Bit Miltiplikation sowie Division recht groß.
Das kann der AVR ja nicht in Hardware, aber wird fürs verrechnen der Kalibrierdaten benötigt.
Guck doch mal in die BME280_compensate_X_int32 Funktionen
Re: Der AVR-/ARDUINO-Faden
Das werd ich mir heut nachmittag noch mal anschauen, aber ich dachte, die printf sind schon auskommentiert. Wenn ich das richtig gelesen habe, hatte man bei Bosch in den Codebeispielen schon darauf geachtet, dass Divisionen primär durch Shift-Befehle erschlagen werden können. Wobei ich denke, dass Shifts größer 8 Bit eigentlich durch Registertausch vereinfacht werden könnten. Aber das sollte gcc selbst auf die Reihe bekommen.
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Das beschleunigt die Ausführungszeit wenn nicht jedesmal die Lib aufgerufen werden muss.
Sobald aber noch ein 32 Bit Mul/Div über bleibt wird die gcc Lib hinzugelinkt.
genatzt!
Ja, das ist eher kryptisch, kommt aber so aus dem DB.
Sobald aber noch ein 32 Bit Mul/Div über bleibt wird die gcc Lib hinzugelinkt.
Code: Alles auswählen
int32_t var1, var2;
uint32_t p;
if (p < 0x80000000L){
p = (p << 1) / ((uint32_t)var1);
}else{
p = (p / (uint32_t)var1) * 2;
}
var1 = (((int32_t)dig_P9) * ((int32_t)(((p>>3) * (p>>3))>>13)))>>12;
Ja, das ist eher kryptisch, kommt aber so aus dem DB.
Re: Der AVR-/ARDUINO-Faden
Jau, das meinte ich. Da sehe ich mich schon mit Kästchenpapier und Bleistift die Rechenbewegungen rausschreiben und in Inline-ASM abwickeln...
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja
Oder eben den Mega16/32/328 nutzen.
Oder auf ARM Umsteigen da gibts Hardware MulDiv in 32Bit.
MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
Oder eben den Mega16/32/328 nutzen.
Oder auf ARM Umsteigen da gibts Hardware MulDiv in 32Bit.
MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
Re: Der AVR-/ARDUINO-Faden
Ist das Teil deiner Doktor/Diplomarbeit? Schon krass, was das für ein Aufwand für Multiplikation/Division istFritzler hat geschrieben: ↑Do 18. Mär 2021, 15:14MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Ne, das is nur Hobby.
Den Text hab ich an ein paar Abenden runtergerasselt, das is doch keine Arbeit.
Aber ich fands erschreckend wie sehr die Fachliteratur so einige Sonderfälle weggelassen hat.
Diese habe ich dann mit diesem 4 Bit Rumschubs C Programm rausgefunden.
Daher musste ich das quasi schreiben auch als Doku für mich zu späterer Zeit.
Zum Aufwand:
Das ist nur ein serieller MulDiv.
Der rechnet nicht paralel, diese wären dann ne Hardwareschlacht bei 32Bit.
Re: Der AVR-/ARDUINO-Faden
Hallo,
ich habe am Balkon einen LED-Streifen mit WS2812. Gesteuert wird das ganze über einen Wemos Mini. Ich nutze das in Verbindung mit einem Türsensor als Balkon-Beleuchtung und je nach Jahreszeit und Feiertag als Dekorationsbeleuchtung. Das Problem ist, dass der Wemos mit seinem WLAN dazwischenfunkt. (Der Gag war einfach zu passend )
Die WS2812 wollen ja alle in einem Rutsch mit Daten gefüttert werden. Wenn aber ein WLAN-Interrupt dazwischenkommt funktioniert das nicht und die LEDs zeigen für eine kurze Zeit etwas falsches an. (Meissten natürlich irgendeine grelle Farbe in voller Helligkeit) Die Nachbarn müssen uns schon für bekloppt halten...
Es gibt zwar die Möglichkeit die Interrupts während der Aktualisierung der LEDs abzuschalten. Dann stürzt aber das Betriebssystem des Wemos gelegentlich ab.
Mein erster Lösungsansatz war andere LEDs mit Clock-Leitung. (z.B. APA102). Die Idee habe ich aber verworfen, weil der aktuelle Stripe schön unsichtbar und wetterfest eingebaut ist.
Meine zweite Idee ist einen Controller dazwischenzuschalten. Da ich WLAN benötige, stelle ich den Wemos z.B. auf APA102 LEDs um. Diesen Datenstrom empfange und speichere ich in einem anderen Controller und dieser gibt den Datenstrom dann passend an meine WS2812 aus. Nach kurzer Überlegung bin ich aber zum Schluss gekommen, dass der Controller dafür aber ganz schön schnell sein muss und auch die Programmierung nicht ganz trivial sein wird. Eigentlich bräuchte ich etwas mit Multithreading.
Die dritte Idee ist ein RAM mit zwei Schnittstellen zu suchen (gibt es ja z.B. in alten 8-Bit Computern, wenn die Grafikeinheit den gleichen RAM wie die CPU nutzt). Dann würden zwei kleine Controller genügen, einer der den APA102 Datenstrom vom Wemos empfängt und in den Ram packt und ein anderer, der aus dem RAM die WS2812 füttert. Eine Handshake-Leitung zwischen den Controllern sollte dann passend sein.
Diese Idee habe ich weiter gesponnen, ob das nicht vielleicht auch nur mit den zwei Controllern ohne RAM dazwischen geht. Dann müsste der erste aber den kompletten Datenstrom zwischenspeichern und dann auf Anfrage an den zweiten weitergeben. Dies kann für die Geschwindigkeit parallel geschehen.
Wer hat noch weitere Ideen oder wie ist eure Meinung zu meinen?
Viele Grüße
Andreas
ich habe am Balkon einen LED-Streifen mit WS2812. Gesteuert wird das ganze über einen Wemos Mini. Ich nutze das in Verbindung mit einem Türsensor als Balkon-Beleuchtung und je nach Jahreszeit und Feiertag als Dekorationsbeleuchtung. Das Problem ist, dass der Wemos mit seinem WLAN dazwischenfunkt. (Der Gag war einfach zu passend )
Die WS2812 wollen ja alle in einem Rutsch mit Daten gefüttert werden. Wenn aber ein WLAN-Interrupt dazwischenkommt funktioniert das nicht und die LEDs zeigen für eine kurze Zeit etwas falsches an. (Meissten natürlich irgendeine grelle Farbe in voller Helligkeit) Die Nachbarn müssen uns schon für bekloppt halten...
Es gibt zwar die Möglichkeit die Interrupts während der Aktualisierung der LEDs abzuschalten. Dann stürzt aber das Betriebssystem des Wemos gelegentlich ab.
Mein erster Lösungsansatz war andere LEDs mit Clock-Leitung. (z.B. APA102). Die Idee habe ich aber verworfen, weil der aktuelle Stripe schön unsichtbar und wetterfest eingebaut ist.
Meine zweite Idee ist einen Controller dazwischenzuschalten. Da ich WLAN benötige, stelle ich den Wemos z.B. auf APA102 LEDs um. Diesen Datenstrom empfange und speichere ich in einem anderen Controller und dieser gibt den Datenstrom dann passend an meine WS2812 aus. Nach kurzer Überlegung bin ich aber zum Schluss gekommen, dass der Controller dafür aber ganz schön schnell sein muss und auch die Programmierung nicht ganz trivial sein wird. Eigentlich bräuchte ich etwas mit Multithreading.
Die dritte Idee ist ein RAM mit zwei Schnittstellen zu suchen (gibt es ja z.B. in alten 8-Bit Computern, wenn die Grafikeinheit den gleichen RAM wie die CPU nutzt). Dann würden zwei kleine Controller genügen, einer der den APA102 Datenstrom vom Wemos empfängt und in den Ram packt und ein anderer, der aus dem RAM die WS2812 füttert. Eine Handshake-Leitung zwischen den Controllern sollte dann passend sein.
Diese Idee habe ich weiter gesponnen, ob das nicht vielleicht auch nur mit den zwei Controllern ohne RAM dazwischen geht. Dann müsste der erste aber den kompletten Datenstrom zwischenspeichern und dann auf Anfrage an den zweiten weitergeben. Dies kann für die Geschwindigkeit parallel geschehen.
Wer hat noch weitere Ideen oder wie ist eure Meinung zu meinen?
Viele Grüße
Andreas
Re: Der AVR-/ARDUINO-Faden
auaua. vielleicht einfacher die Absturz Ursache zu beseitigen.?
muss doch erlaubt sein den interupt auszusetzen.?
muss doch erlaubt sein den interupt auszusetzen.?
- Später Gast
- Beiträge: 1697
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
die Ente lieferte bei "ws2812 interrupt free" dieses Ergebnis. Hab mir das noch nicht näher angeschaut, aber könnte was sein?
Re: Der AVR-/ARDUINO-Faden
Hallo,
@Später Gast: Danke für den Hinweis. In deinem Link wird ein Teensy genutzt. Der läuft meines Wissens nach mit 96 MHz. Das wäre dann wie im Beispiel meines ersten Lösungsansatz. In deinem Link wird auch DMA vorgeschlagen. Dies kann meine Bibliothek leider nicht und müsste dann auch in einem "Thread" laufen, der von den WLAN-IRQs nicht gestört wird oder? Ist der ESP8266 im Wemos dazu fähig?
Viele Grüße
Andreas
Wie ich geschrieben habe liegt die Ursache im Betriebssystem des Wemos. Da habe ich keine Möglichkeit etwas zu ändern und es ist scheinbar nicht vorgesehen die Interrupts zu deaktivieren, wenn WLAN aktiv ist. Solltest du ein Beispiel haben, wie das trotzdem geht wäre ich sehr dankbar, das würde mir viel Arbeit ersparen. Ansonsten wäre es nett wenn du deine Ausdrucksweise überdenkst, bevor du mich für dumm erklärst.
@Später Gast: Danke für den Hinweis. In deinem Link wird ein Teensy genutzt. Der läuft meines Wissens nach mit 96 MHz. Das wäre dann wie im Beispiel meines ersten Lösungsansatz. In deinem Link wird auch DMA vorgeschlagen. Dies kann meine Bibliothek leider nicht und müsste dann auch in einem "Thread" laufen, der von den WLAN-IRQs nicht gestört wird oder? Ist der ESP8266 im Wemos dazu fähig?
Viele Grüße
Andreas
Re: Der AVR-/ARDUINO-Faden
das war nicht meine Absicht. edit. erschrickt mich sogar etwas, das du es so aufgefasst hast, sorry.
ich hab in anderem Zusammenhang auch schon über verteilte uC nachgedacht. mich hats dann aber vor dem Aufwand gegruselt. daher auaua.
Zuletzt geändert von ch_ris am So 21. Mär 2021, 09:10, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
Zur Ansteuerung der LED's kannst Du auch einen Raspberry Pi PIco nehmen.
Da gibts ein Beispiel, da ist das zeitkritische Protokoll mit den neuen PIO Hardware-Dingsbums-Prozessoren gemacht.
Absolut schnell und sauber. Belastet die beiden Cortex M0 Prozessoren gar nicht.
Geht RatzeFatze. In MicroPython ein paar Zeile Code, kostet 4.-€ ...
https://www.raspberrypi.org/blog/neopix ... with-pico/
Da gibts ein Beispiel, da ist das zeitkritische Protokoll mit den neuen PIO Hardware-Dingsbums-Prozessoren gemacht.
Absolut schnell und sauber. Belastet die beiden Cortex M0 Prozessoren gar nicht.
Geht RatzeFatze. In MicroPython ein paar Zeile Code, kostet 4.-€ ...
https://www.raspberrypi.org/blog/neopix ... with-pico/
Re: Der AVR-/ARDUINO-Faden
Hallo, Harley,
über den Pico habe ich ebenfalls schon nachgedacht. Das wäre ja wieder mein Lösungsvorschlag 1. Ich kenne den bisher nicht, aber soweit ich informiert bin kann der offiziel 2 Threads. Ich habe allerdings noch nie etwas in Phyton progrmamiert. Da ich gleich mit Hardware-IRQs und Multithreading los legen müsste habe ich gehofft diese steile Lernkurve umgehen zu können.
@ch_ris: Kein Problem, dann handelt es sich nur um ein Missverständnis. Schwamm drüber.
Nach meinen Berechnungen hat ein Standard AVR @ 16 MHz nur 6 Taktzyklen, bis er das nächste "Halbbit" wackeln muss bei der geforderten Taktfrequenz von 800 kHz. Da ist nicht mehr viel Zeit übrig, in der die Daten auch noch empfangen werden. Wenn die Daten dann noch zu einem beliebeigen Zeitpunkt ankommen sehe ich eigentlich gar keine Möglichkeit.
Es ist erstaunlich, dass dieses Problem meines Wissens nach im Netz schon seit über 4 Jahren besteht und ich habe zumindest bis jetzt noch keine vernünftige Lösung dafür gefunden.
Viele Grüße
Andreas
über den Pico habe ich ebenfalls schon nachgedacht. Das wäre ja wieder mein Lösungsvorschlag 1. Ich kenne den bisher nicht, aber soweit ich informiert bin kann der offiziel 2 Threads. Ich habe allerdings noch nie etwas in Phyton progrmamiert. Da ich gleich mit Hardware-IRQs und Multithreading los legen müsste habe ich gehofft diese steile Lernkurve umgehen zu können.
@ch_ris: Kein Problem, dann handelt es sich nur um ein Missverständnis. Schwamm drüber.
Nach meinen Berechnungen hat ein Standard AVR @ 16 MHz nur 6 Taktzyklen, bis er das nächste "Halbbit" wackeln muss bei der geforderten Taktfrequenz von 800 kHz. Da ist nicht mehr viel Zeit übrig, in der die Daten auch noch empfangen werden. Wenn die Daten dann noch zu einem beliebeigen Zeitpunkt ankommen sehe ich eigentlich gar keine Möglichkeit.
Es ist erstaunlich, dass dieses Problem meines Wissens nach im Netz schon seit über 4 Jahren besteht und ich habe zumindest bis jetzt noch keine vernünftige Lösung dafür gefunden.
Viele Grüße
Andreas
Re: Der AVR-/ARDUINO-Faden
Dann wirds Zeit, mit der Python Programmierung anzufangen!
Ich hab doch oben die ultimative Lösung verlinkt.
Einfach abtippen und loslegen.
Die Lernkurve beim Pico ist wirklich sehr flach.
Schau mal hier vorbei:
https://www.youtube.com/c/PrintNPlay/videos
Im obigen Beispiel schreibt der Autor:
We’re going to look at how two features of Pico help solve these problems. Firstly, Programmable I/O (PIO) lets us implement the control protocol on a state machine rather than the main processing cores. This means that we don’t have to dedicate any processor time to sending the data out. Secondly, having two cores means we can use one of the processing cores to dither the NeoPixels. This means shift them rapidly between different brightness levels to make pseudo-levels of brightness.
Das ist genau das, was Du brauchst.
Die Datenausgabe läuft hochpräzise in einer State-Machine. Der Core Nr.1 kümmert sich um das Dithering. Core Nr.2 schaufelt in aller Ruhe die Daten hin und her.
Ich hab doch oben die ultimative Lösung verlinkt.
Einfach abtippen und loslegen.
Die Lernkurve beim Pico ist wirklich sehr flach.
Schau mal hier vorbei:
https://www.youtube.com/c/PrintNPlay/videos
Im obigen Beispiel schreibt der Autor:
We’re going to look at how two features of Pico help solve these problems. Firstly, Programmable I/O (PIO) lets us implement the control protocol on a state machine rather than the main processing cores. This means that we don’t have to dedicate any processor time to sending the data out. Secondly, having two cores means we can use one of the processing cores to dither the NeoPixels. This means shift them rapidly between different brightness levels to make pseudo-levels of brightness.
Das ist genau das, was Du brauchst.
Die Datenausgabe läuft hochpräzise in einer State-Machine. Der Core Nr.1 kümmert sich um das Dithering. Core Nr.2 schaufelt in aller Ruhe die Daten hin und her.
Re: Der AVR-/ARDUINO-Faden
Wie wird das bei WLED gelöst, damit habe ich schon einige WS2812 mit angebunden und da flickert nichts. Oder ist mir nicht aufgefallen.
- Später Gast
- Beiträge: 1697
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Also wenn ich das in meiner morgendlichen Verpeiltheit grad nicht komplett falsch verstehe, wird der Pico in der IDE bereits nativ unterstützt.
Muss ich wohl auch mal welche ordern
Muss ich wohl auch mal welche ordern
Re: Der AVR-/ARDUINO-Faden
Hallo,
ich habe auch mal gegoogelt. Der Support in der Arduino-IDE ist scheinbar erst angekündigt. Mal schauen, wie lange es dauert.
Viele Grüße
Andreas
ich habe auch mal gegoogelt. Der Support in der Arduino-IDE ist scheinbar erst angekündigt. Mal schauen, wie lange es dauert.
Viele Grüße
Andreas
Re: Der AVR-/ARDUINO-Faden
Ha! Es geht doch. 6,2 kb Flashauslastung. Ich habe jetzt einfach noch mal den Code "from Scratch" zusammengebaut. Anscheinend war es keine clevere Idee, den Modbuscode aus einem anderen Projekt zu übernehmen, auch wenn dort nette Zusatzfunktionen wie über Register einstellbare Baudrate/Adresse mit drin waren.Fritzler hat geschrieben: ↑Do 18. Mär 2021, 15:14 Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja
Oder eben den Mega16/32/328 nutzen.
Oder auf ARM Umsteigen da gibts Hardware MulDiv in 32Bit.
MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
Ich habe jetzt eine Statische Adresse, die bekommt aber als nächstes die unteren 4 Bit über eine Port eingelesen (Jumper).
Abgesehen davon, scheint ausserdem der Speicherbedarf proportional zum Alter des avr-gcc uu sein - habe am Samstag extra Eclipse/Avr/avr-gcc neu auf meinem Büro-PC installiert und diese Fassung zusammengebaut, der erste Versuch war mit avr-gcc aus ubuntu 18.04...
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Ja, der AVR Pfad des GCC ist eher verwaist.
Im GCC11 droht es ganz rauszufliegen, weil das keiner mehr anfasst, aber große Änderungen anstehen.
Selbst Microchip juckts nicht wirklich, die haben nur 5000€ in den Kopfgeldpool geworfen.
Die wollen einen wohl zum mplab zwingen. (sau gruselige Software)
Meine Empfehlung wäre GCC 4.7 oder 4.9.2, da geht schon _flash statt progmem und es ist noch eher klein.
Man merkt eben, das die AVRs auf dem absteigenden Ast sitzen, auch wenn noch ein paar neue Tinys rauskamen.
Modbus ist ja auch ein sehr einfaches Protokoll, das ist nur Zeitaufwand den man für die Lib investieren muss.
Ich hab mir ja auch ascon eine Modbuslib gezimmert.
Da hab ich aber eher auf vollständigkeit statt platzersparnis geachtet.
Im GCC11 droht es ganz rauszufliegen, weil das keiner mehr anfasst, aber große Änderungen anstehen.
Selbst Microchip juckts nicht wirklich, die haben nur 5000€ in den Kopfgeldpool geworfen.
Die wollen einen wohl zum mplab zwingen. (sau gruselige Software)
Meine Empfehlung wäre GCC 4.7 oder 4.9.2, da geht schon _flash statt progmem und es ist noch eher klein.
Man merkt eben, das die AVRs auf dem absteigenden Ast sitzen, auch wenn noch ein paar neue Tinys rauskamen.
Modbus ist ja auch ein sehr einfaches Protokoll, das ist nur Zeitaufwand den man für die Lib investieren muss.
Ich hab mir ja auch ascon eine Modbuslib gezimmert.
Da hab ich aber eher auf vollständigkeit statt platzersparnis geachtet.
Re: Der AVR-/ARDUINO-Faden
Hallo,
immer wenn ich denke das ich schon ganz schön gut mit der ArduinoKiste bin......
muss ich nur einen Beitrag von Fritzler lesen, daß sortiert mich dann gleich wieder weiter unten ein.
Aber kurz noch was anderes bin so beim Rumgooglen auf das hier gestossen:
https://www.robotfreak.de/blog/asuro-di ... %20Yeti%29.
Kann man sich nicht aus diese Not eine Tugend machen?
Also mal angenommen ich habe so einen Nano und der ist blöd verbaut bzw. ich habe schlecht Möglicheiten Steckverbindungen zu machen.
Dezent ein kleines Bohrloch und dann über IR Flashen?
Ist das möglich?
cu
jodurino
immer wenn ich denke das ich schon ganz schön gut mit der ArduinoKiste bin......
muss ich nur einen Beitrag von Fritzler lesen, daß sortiert mich dann gleich wieder weiter unten ein.
Aber kurz noch was anderes bin so beim Rumgooglen auf das hier gestossen:
https://www.robotfreak.de/blog/asuro-di ... %20Yeti%29.
Kann man sich nicht aus diese Not eine Tugend machen?
Also mal angenommen ich habe so einen Nano und der ist blöd verbaut bzw. ich habe schlecht Möglicheiten Steckverbindungen zu machen.
Dezent ein kleines Bohrloch und dann über IR Flashen?
Ist das möglich?
cu
jodurino
Re: Der AVR-/ARDUINO-Faden
Seriell und Infrarot hatten wir in den 90ern schon mal am Handy, nannte sich IrDa. Dazu muss neben der Schnittstelle ein passender Bootloader drauf, dann sollte das schon gehen.
Re: Der AVR-/ARDUINO-Faden
Habe gerade ein Problem mit einer eigentlich simplen Aufgabe.
Ein Schrittmotor mit DRV 8825 soll immer die selbe Anzahl Steps ausführen, dann eine Zeit
warten und wieder dann weiter drehen. Also quasi als endlos ablaufende Schleife.
Ich weiß aber nicht, wie man eine bestimmte Anzahl steps definiert und das dann laufen lässt.
Hat jemand da eine (einfache) Idee, wie das gehen kann?
Ein Schrittmotor mit DRV 8825 soll immer die selbe Anzahl Steps ausführen, dann eine Zeit
warten und wieder dann weiter drehen. Also quasi als endlos ablaufende Schleife.
Ich weiß aber nicht, wie man eine bestimmte Anzahl steps definiert und das dann laufen lässt.
Hat jemand da eine (einfache) Idee, wie das gehen kann?
Re: Der AVR-/ARDUINO-Faden
Moin,
ich versuche mich gerade an einer ds18B20 Geschichte:
Am Arduino hängen mehrere 18B20.
Die will ich mit Serialnummer auslesen, das Script tut das auch, soweit prima.
Aber ich kann die deviceAddress nicht weiter verarbeiten, da es sich um ein ?byte Array? handelt?
Mit "DeviceAddress deviceAddress" wird das zu einem byte[8] Array deklariert
Ich will aber die Seriennummer später in einem mqtt-Topic haben, dort ist ein char* gefordert.
Wenn ich
mache, wird es in der Seriellen Konsole prima angezeigt
Wie bekomme ich "deviceAddress" in char* gepresst?
es soll so aussehen:
ich versuche mich gerade an einer ds18B20 Geschichte:
Am Arduino hängen mehrere 18B20.
Die will ich mit Serialnummer auslesen, das Script tut das auch, soweit prima.
Aber ich kann die deviceAddress nicht weiter verarbeiten, da es sich um ein ?byte Array? handelt?
Mit "DeviceAddress deviceAddress" wird das zu einem byte[8] Array deklariert
Ich will aber die Seriennummer später in einem mqtt-Topic haben, dort ist ein char* gefordert.
Wenn ich
Code: Alles auswählen
for (uint8_t i = 0; i < 8; i++) {
Serial.print(deviceAddress[i], HEX);
}
Wie bekomme ich "deviceAddress" in char* gepresst?
es soll so aussehen:
Code: Alles auswählen
sensors.requestTemperatures();
for (int i = 0; i < deviceCount; i++) {
sensors.getAddress(deviceAddress, i);
String sensorID = deviceAddress;
tempC = sensors.getTempCByIndex(i);
hier brauche ich einen String aus Topic und sensorID :TOPIC= "Ardu1/"+sensorID+"/"
client.publish(TOPIC, tempC);
}
Code: Alles auswählen
/*
Basic MQTT example
This sketch demonstrates the basic capabilities of the library.
It connects to an MQTT server then:
- publishes "hello world" to the topic "outTopic"
- subscribes to the topic "inTopic", printing out any messages
it receives. NB - it assumes the received payloads are strings not binary
It will reconnect to the server if the connection is lost using a blocking
reconnect function. See the 'mqtt_reconnect_nonblocking' example for how to
achieve the same result without blocking the main loop.
*/
#include <SPI.h>
#include <EthernetENC.h>
#include <PubSubClient.h>
#include <OneWire.h>
#include <DallasTemperature.h>
// Define to which pin of the Arduino the 1-Wire bus is connected:
#define ONE_WIRE_BUS 4
// Create a new instance of the oneWire class to communicate with any OneWire device:
OneWire oneWire(ONE_WIRE_BUS);
// Pass the oneWire reference to DallasTemperature library:
DallasTemperature sensors(&oneWire);
// Create variables:
int deviceCount = 0; // variable to store the number of devices connected
DeviceAddress deviceAddress; // variable to store the device address
float tempC;
// Update these with values suitable for your network.
byte mac[] = { 0xDE, 0xED, 0xBA, 0xFE, 0xFE, 0xED };
IPAddress ip(192, 168, 1, 16);
IPAddress server(192, 168, 1, 200);
char* TOPIC = "ardu1";
char* MSG = "test";
int ledPin1=2;
int ledPin2=3;
int MielePin=14;
int WasserPin=15;
int KlimaPin=16;
void printAddress(DeviceAddress deviceAddress) {
for (uint8_t i = 0; i < 8; i++) {
Serial.print(deviceAddress[i], HEX);
}
}
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i=0;i<length;i++) {
Serial.print((char)payload[i]);
}
Serial.println();
}
EthernetClient ethClient;
PubSubClient client(ethClient);
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
digitalWrite(ledPin1,LOW);
digitalWrite(ledPin2,HIGH);
Serial.print("Attempting MQTT connection...");
// Attempt to connect
if (client.connect("arduinoClient")) {
digitalWrite(ledPin1,HIGH);
digitalWrite(ledPin2,LOW);
Serial.println("connected");
// Once connected, publish an announcement...
client.publish(TOPIC, "Restart");
// ... and resubscribe
//#client.subscribe("inTopic");
}
else {
digitalWrite(ledPin1,LOW);
digitalWrite(ledPin2,HIGH);
Serial.print("failed, rc=");
Serial.print(client.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(1000);
}
}
}
void setup()
{
sensors.begin();
pinMode(ledPin1,OUTPUT);
pinMode(ledPin2, OUTPUT);
pinMode(MielePin,INPUT);
pinMode(WasserPin,INPUT);
pinMode(KlimaPin,OUTPUT);
digitalWrite(ledPin1,LOW);
digitalWrite(ledPin2,HIGH);
digitalWrite(MielePin,HIGH);
digitalWrite(WasserPin,HIGH);
digitalWrite(KlimaPin,LOW);
Serial.begin(19200);
client.setServer(server, 1883);
client.setCallback(callback);
Ethernet.begin(mac, ip);
// Allow the hardware to sort itself out
delay(1500);
// Locate the devices on the bus:
Serial.println("Locating devices...");
Serial.print("Found ");
deviceCount = sensors.getDeviceCount();
Serial.print(deviceCount);
Serial.println(" devices");
Serial.println("Printing addresses...");
for (int i = 0; i < deviceCount; i++) {
Serial.print("Sensor ");
Serial.print(i + 1);
Serial.print(" : ");
sensors.getAddress(deviceAddress, i);
printAddress(deviceAddress[i]);
Serial.println();
}
}
void loop()
{
sensors.requestTemperatures();
for (int i = 0; i < deviceCount; i++) {
Serial.print("Sensor ");
sensors.getAddress(deviceAddress, i);
String sensorID = deviceAddress;
Serial.print(sensorID);
Serial.print(" : ");
tempC = sensors.getTempCByIndex(i);
Serial.print(tempC);
Serial.print(" \xC2\xB0"); // shows degree symbol
Serial.print("C | ");
Serial.println();
}
//client.subscribe("power/Leistung");
digitalWrite(ledPin1, HIGH);
if (digitalRead(MielePin)==LOW){
client.publish(TOPIC, "Miele_Fertig");
delay(500);
}
if (digitalRead(WasserPin)==LOW){
client.publish(TOPIC, "Wasser_Alarm");
delay(500);
}
if (!client.connected()) {
//digitalWrite(ledPin1, LOW);
reconnect();
}
client.loop();
}
Re: Der AVR-/ARDUINO-Faden
Wahrscheinlich die eleganteste Variante wäre "sprintf()" zu verwenden. Weil du dort auch die Hex-Werte gleich in Buchstaben umwandeln kannst. Ich habe das in einem Codebeispiel auf uC.net gesehen, da ging es auch um die 1W Adressen: https://www.mikrocontroller.net/topic/14792
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
snprintf!
https://www.cplusplus.com/reference/cstdio/snprintf/
Wer sprintf nutzt hat Hiebe mit der Lankabelpeitsche verdient
https://www.cplusplus.com/reference/cstdio/snprintf/
Wer sprintf nutzt hat Hiebe mit der Lankabelpeitsche verdient
Re: Der AVR-/ARDUINO-Faden
Natürlich, wenn, dann richtig (und sicher). Ich geh dann mal in meinen Folterkeller
Re: Der AVR-/ARDUINO-Faden
Ich will ja nicht den Kram auf der Seriellen Schnittstelle ausgeben das geht ja.
Re: Der AVR-/ARDUINO-Faden
Mit den s(n)printf baust du in erster Linie einen String zusammen. Den kannst du dann wieder nach belieben weiterverwursten...
Re: Der AVR-/ARDUINO-Faden
Wer gaaaaaanz genau weiss, was er tut, kann natürlich sprintf() benutzen. Abertausende von C-Programmier haben das tagtäglich gemacht.Fritzler hat geschrieben: ↑Di 6. Apr 2021, 08:51 snprintf!
https://www.cplusplus.com/reference/cstdio/snprintf/
Wer sprintf nutzt hat Hiebe mit der Lankabelpeitsche verdient
Viele sind dabei nicht auf die Nase gefallen - einige aber doch...
Will man z.B. einen 8-bit-Wert als Dezimalwert ausdrucken, kann das Ergebnis maximal 3-stellig werden. Plus das terminierende '/0' reicht dann ganz sicher ein char[4]. Aber Gnade Gott, jemand schraubt am Programm und versucht sich mit einen 16-bit-Wert ...
Mit snprintf() ist man auf der sicheren Seite und kann zumindest mal einen Bufferüberlauf vermeiden - sofern man das 'n' und den char[]-Buffer richtig aufeinander abstimmt.
Genau genommen muss man aber den Rückgabewert von snprintf() prüfen, um Situationen abzufangen, wenn der Buffer doch mal zu klein gewählt war.
So oder so muss man sich also im Klaren sein, wie groß man den Buffer dimensioniert. Das nimmt einem auch snprintf() nicht ab.
Allgemein sollte man alle str-Funktionen (auch schon in C) vermeiden. Besser man benutzt die strn-Funktionen, also z.B. strncpy() statt strcpy() .
Anm.: In alten C-Libraries (vor C99 ?) gibt es noch kein snprintf().
Re: Der AVR-/ARDUINO-Faden
Das ist alles ganz schön hässlich:
Die Temperatur kommt als float und muss in ein char*
Die Adresse kommt als byte[8] Array und muss auch in ein char* und ich muss da noch Konstanten Text String rein drücken und noch ein paar „/„ einfügen.
Die Temperatur kommt als float und muss in ein char*
Die Adresse kommt als byte[8] Array und muss auch in ein char* und ich muss da noch Konstanten Text String rein drücken und noch ein paar „/„ einfügen.
Re: Der AVR-/ARDUINO-Faden
Kuck dir mal den Format-String der printf()-Familie, also auch snprintf() an.
Kannst mal einen Hexdump der Adresse und der Temp schicken?
Edith meint ich soll ein Beispiel anhängen ....
Muss bei dir nicht passen, aber für den Fall du wolltest eine IP-Adresse drucken. Die 4 Bytes stehen im Array byte adr[] = { 0xc0, 0xa6, 0x37, 0x11 };
Ein printf("%d:%d:%d:%d\n", adr[0], adr[1], adr[2], adr[3]); spuckt dann 192:168:55:17 aus.
Schreibst statt %d etwa %03d wirft er 192:168:055:017 aus.
Willst du's in hex, dann ersetzt du das %d durch %x.
Statt "%d:%d:%d:%d\n" geht aus sowas: "Adresse ist %d/%d/%d/%d - sieht gut aus, oder?\n"
schmeißt raus: Adresse ist 192/168/55/17 - sieht gut aus, oder?
Siehe auch "printf" auf Wikipedia.
Re: Der AVR-/ARDUINO-Faden
Habt ihr schon die 2.0 IDE benutzt? OK, ist n Beta,aber die Compilermeldungen sind plötzlich extrem unbrauchbar und kaum geeignet, Fehler zu finden. Man wird zugespammt mit Informationen und unten drunter steht der lapidare Satz : "Compilation error: Error: 2 UNKNOWN: exit status 1". Das zum Beispiel eine Bibliothek fehlt muss ich mir aus 2k Text rauspopeln mit der Information (ohne Zeilennummer!):
ResolveLibrary(wurst.h)
-> candidates: []
Schalte ich "Verbose" ab, kommt noch nicht einmal mehr diese Meldung, sondern nur noch "Compilation error: Error: 2 UNKNOWN: exit status 1"
Was ich ehr bizarr finde: das scheint da draussen im Gewebe keinen zu stören. Was meint ihr dazu?
ResolveLibrary(wurst.h)
-> candidates: []
Schalte ich "Verbose" ab, kommt noch nicht einmal mehr diese Meldung, sondern nur noch "Compilation error: Error: 2 UNKNOWN: exit status 1"
Was ich ehr bizarr finde: das scheint da draussen im Gewebe keinen zu stören. Was meint ihr dazu?
Re: Der AVR-/ARDUINO-Faden
Es gibt einen Bug Report dafür:
https://github.com/arduino/arduino-ide/issues/249
ähnlich gelagert:
https://github.com/arduino/arduino-ide/issues/215
Man arbeitet dran. Ist ja ne Beta.
https://github.com/arduino/arduino-ide/issues/249
ähnlich gelagert:
https://github.com/arduino/arduino-ide/issues/215
Man arbeitet dran. Ist ja ne Beta.
Re: Der AVR-/ARDUINO-Faden
Wenn der Motor sehr langsam laufen soll geht das recht einfach. Für höhere Geschwindigkeiten braucht man aber eine Beschleunigungs- und Bremsrampe, sonst verliert der Motor Schritte.Cubicany hat geschrieben: ↑Mo 5. Apr 2021, 12:29 Ein Schrittmotor mit DRV 8825 soll immer die selbe Anzahl Steps ausführen, dann eine Zeit
warten und wieder dann weiter drehen. Also quasi als endlos ablaufende Schleife.
Ich weiß aber nicht, wie man eine bestimmte Anzahl steps definiert und das dann laufen lässt.
Nachfolgend ein Programm, das deinen Stepper 100 Schritte mit 10 Schritten pro Sekunde drehen läßt, 2s Pause macht und dann wieder 100 Schritte dreht.
Code: Alles auswählen
#define Schrittzahl 100
#define pausenzeit_ms 2000 //Wartezeit
#define schrittzeit_ms 50 // 500/Schritte-pro-Sekunde. Hier: 10 Steps/s
#define DO_STEP 2 //Digital Out "STEP" an Pin 2
void setup() {
pinMode(DO_STEP, OUTPUT);
}
void loop() {
for (int i=0; i < Schrittzahl; i++) {
digitalWrite(DO_STEP, HIGH);
delay(schrittzeit_ms);
digitalWrite(DO_STEP, LOW);
delay(schrittzeit_ms);
}
delay(pausenzeit_ms);
}
Gruß,
Zabex
Re: Der AVR-/ARDUINO-Faden
Habe mir die MobaTools (hat man mir in der Arduino Community empfohlen)runter geladen und mit etwas Hilfe schon geschafft, über einen Taster
die immer gleiche Zahl steps mit Anfahr und Bremsverhalten zu realisieren.
So:
Jetzt will ich noch über einen Wahlschalter entscheiden ob links oder recht rum gedreht wird.
die immer gleiche Zahl steps mit Anfahr und Bremsverhalten zu realisieren.
So:
Code: Alles auswählen
#include <MobaTools.h>
const byte stepPin = 3;
const byte dirPin = 2;
const byte tasterPin = 4; // Taster zwischen Pin und Gnd anschließen
const byte tasterPin2 = 5;
const int stepsProUmdr = 800; // Steps pro Umdrehung ( mit 1/4 microsteps )
int stepsProTaster = 800; // Schritte um die sich der Motor pro Tastendruck dreht.
// Bei Dauerdruck dreht er sich ständig weiter
MoToStepper myStepper ( stepsProUmdr, STEPDIR );
void setup() {
myStepper.attach( stepPin, dirPin );
myStepper.setSpeed( 1000 ); // 60 Umdrehungen/Min
myStepper.setRampLen( 100 );
pinMode( tasterPin, INPUT_PULLUP );
}
void loop()
{
if ( digitalRead(tasterPin) == LOW && not myStepper.moving() ) {
myStepper.doSteps( stepsProTaster );
}
}
Re: Der AVR-/ARDUINO-Faden
Der Arduino printf("%d:%d:%d:%d\n", adr[0], adr[1], adr[2], adr[3]); kann anscheinend kein float.
wenn ich
float zahl=12.23;
char buffer[5];
snprintf(text, 5,"%2.2f", zahl);
Serial.print(text);
mache kommen nur " ?" egal was ich da an Formatierungen mache
Das hingegen klappt:
dtostrf(zahl,3,2, text); //Variable von float zu char* umwandeln
wenn ich
float zahl=12.23;
char buffer[5];
snprintf(text, 5,"%2.2f", zahl);
Serial.print(text);
mache kommen nur " ?" egal was ich da an Formatierungen mache
Das hingegen klappt:
dtostrf(zahl,3,2, text); //Variable von float zu char* umwandeln
Re: Der AVR-/ARDUINO-Faden
Man könnte das float wohl in der Lib freischalten. Hab ich aber noch nie gemacht.
Ich hab mir mit Division und Modulo die Vor- und Nachkommastellen hingebastelt und die 2 Teile dann mit %d.02d gedruckt
Ich hab mir mit Division und Modulo die Vor- und Nachkommastellen hingebastelt und die 2 Teile dann mit %d.02d gedruckt
Re: Der AVR-/ARDUINO-Faden
herrje, ein Kumpel möchte uC zeug anfangen. Programmierer bzw. Informatiker isser.
Hat sich ein Mega Starter Set bestellt.
Ziel ist ein Schach Computer.
Da läuft dann eine Schach engine auf einem PI,
der AVR treibt "nur" das Schachbrett.
dabei soll er die Züge erfassen, also das Brett als Interface dienen. Figuren sollen gesteckt werden, also unten einen PIN haben.
1: der mega hat 54 io Pins. mit 2-3 8fach multiplexern zusätzlich, könnte man jedes Feld einzeln erfassen
(64 (Um)Schalter)
2: mit 2 8fach multiplexern könnte man eine Matrix erfassen.
(128 taster; 64 LEDs)
3: Tastatur zerlegen/missbrauchen (ohne AVR), tät ich wohl machen, er möchte ja aber ControllerZeugs anfangen, was sehr löblich ist.
wie macht man's am elegantesten?
beim drüber nachdenken gruselt's mich schon, gut das ich den Kolben da nicht schwingen muss
Hat sich ein Mega Starter Set bestellt.
Ziel ist ein Schach Computer.
Da läuft dann eine Schach engine auf einem PI,
der AVR treibt "nur" das Schachbrett.
dabei soll er die Züge erfassen, also das Brett als Interface dienen. Figuren sollen gesteckt werden, also unten einen PIN haben.
1: der mega hat 54 io Pins. mit 2-3 8fach multiplexern zusätzlich, könnte man jedes Feld einzeln erfassen
(64 (Um)Schalter)
2: mit 2 8fach multiplexern könnte man eine Matrix erfassen.
(128 taster; 64 LEDs)
3: Tastatur zerlegen/missbrauchen (ohne AVR), tät ich wohl machen, er möchte ja aber ControllerZeugs anfangen, was sehr löblich ist.
wie macht man's am elegantesten?
beim drüber nachdenken gruselt's mich schon, gut das ich den Kolben da nicht schwingen muss
Re: Der AVR-/ARDUINO-Faden
Für Schachcomputer würde ich eine Hallmatrix nehmen.
Dann ist die Erkennung der Figur automatisch.
Dann ist die Erkennung der Figur automatisch.
Re: Der AVR-/ARDUINO-Faden
äh, sowas hier?
https://www.stochastik-in-der-schule.de ... Eisenh.pdf
kann ich mir jetzt gar nichts drunter vorstellen, aber der Proband ist ja auch mathe-fuchs, ein bisschen.
https://www.stochastik-in-der-schule.de ... Eisenh.pdf
kann ich mir jetzt gar nichts drunter vorstellen, aber der Proband ist ja auch mathe-fuchs, ein bisschen.
Re: Der AVR-/ARDUINO-Faden
Du meinst eine Wäägezelle unter jedes Feld und jede Figur hat ein definiertes, sich von den anderen unterscheidendes Gewicht?
Dienstlich hatte ich mal einen "OneWire-Button".
Sah aus wie eine Knopfzelle am Plastestiel und musste zur Türöffnung an das Lesegerät gedrückt werden.
Wenn man jede Schachfigur mit so einem "Button" ausstattet...
Induktiv könnte auch funktionieren. Analog als auch Digital.
Dienstlich hatte ich mal einen "OneWire-Button".
Sah aus wie eine Knopfzelle am Plastestiel und musste zur Türöffnung an das Lesegerät gedrückt werden.
Wenn man jede Schachfigur mit so einem "Button" ausstattet...
Induktiv könnte auch funktionieren. Analog als auch Digital.
Re: Der AVR-/ARDUINO-Faden
näh, hör uff.
das schachding weis ja wer wo steht.
muss ja nur, Figur entnommen und figur wieder gesetzt, erkennen.
an die regeln muss man sich schon selbst halten, is ja kein saufspiel.
der mega hat ja 16 adc kanäle, hab ihm empfohlen da 4fach widerstands Kaskaden dranzuhängen.
das schachding weis ja wer wo steht.
muss ja nur, Figur entnommen und figur wieder gesetzt, erkennen.
an die regeln muss man sich schon selbst halten, is ja kein saufspiel.
der mega hat ja 16 adc kanäle, hab ihm empfohlen da 4fach widerstands Kaskaden dranzuhängen.
Re: Der AVR-/ARDUINO-Faden
Wer es noch nicht kennt:
http://eleccelerator.com/fusecalc/fusec ... atmega2560
FuseCalculator für die Avrs mit avrdude CLI Ausgabe
zB:
AVRDUDE -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFD:m -U lock:w:0xFF:m
http://eleccelerator.com/fusecalc/fusec ... atmega2560
FuseCalculator für die Avrs mit avrdude CLI Ausgabe
zB:
AVRDUDE -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFD:m -U lock:w:0xFF:m