Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Anse
Beiträge: 2304
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Schneller Optokoppler klingt nach einem Job für 6N137. Bis 10 MHz und gleich mit schönem logik Level Ausgang.
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

jodurino hat geschrieben: Di 16. Mär 2021, 20:14 ja aus dem Inverter kommt ein Optokoppler fähiges Signal.
Ich seh jetzt nichts was gegen einen Optokoppler sprechen sollte. Mach halt einen rein, wenn dir die galvanische Trennung wichtig ist.
jodurino
Beiträge: 2106
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Anse hat geschrieben: Di 16. Mär 2021, 20:32 Schneller Optokoppler klingt nach einem Job für 6N137. Bis 10 MHz und gleich mit schönem logik Level Ausgang.
Nun mehr als 10kHz erwarte ich da nicht
j.o.e hat geschrieben: Di 16. Mär 2021, 20:38
jodurino hat geschrieben: Di 16. Mär 2021, 20:14 ja aus dem Inverter kommt ein Optokoppler fähiges Signal.
Ich seh jetzt nichts was gegen einen Optokoppler sprechen sollte. Mach halt einen rein, wenn dir die galvanische Trennung wichtig ist.
Ja ist ja im Auto
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

@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 :x
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

sukram hat geschrieben: Mi 17. Mär 2021, 22:51 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.
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 :lol:
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

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.
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.

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;
genatzt!

Ja, das ist eher kryptisch, kommt aber so aus dem DB.
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Jau, das meinte ich. Da sehe ich mich schon mit Kästchenpapier und Bleistift die Rechenbewegungen rausschreiben und in Inline-ASM abwickeln... :?
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja :lol:
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
MSG
Beiträge: 2196
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Fritzler 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
Ist das Teil deiner Doktor/Diplomarbeit? Schon krass, was das für ein Aufwand für Multiplikation/Division ist :o
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

MSG hat geschrieben: Do 18. Mär 2021, 19:45 Ist das Teil deiner Doktor/Diplomarbeit? Schon krass, was das für ein Aufwand für Multiplikation/Division ist :o
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.
MSG
Beiträge: 2196
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Fritzler hat geschrieben: Do 18. Mär 2021, 19:49Ne, das is nur Hobby.
Den Text hab ich an ein paar Abenden runtergerasselt, das is doch keine Arbeit.
*staun* du hast meinen größten Respekt :)
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

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 :D )

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
ch_ris
Beiträge: 3042
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

auaua. vielleicht einfacher die Absturz Ursache zu beseitigen.?
muss doch erlaubt sein den interupt auszusetzen.?
Benutzeravatar
Später Gast
Beiträge: 1699
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

die Ente lieferte bei "ws2812 interrupt free" dieses Ergebnis. Hab mir das noch nicht näher angeschaut, aber könnte was sein?
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

Hallo,
ch_ris hat geschrieben: Sa 20. Mär 2021, 13:48 auaua. vielleicht einfacher die Absturz Ursache zu beseitigen.?
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
ch_ris
Beiträge: 3042
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

:?:
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.
Benutzeravatar
Harley
Beiträge: 1161
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

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/
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

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
Benutzeravatar
Harley
Beiträge: 1161
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Dann wirds Zeit, mit der Python Programmierung anzufangen! :D
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.
Benutzeravatar
phettsack
Beiträge: 1203
Registriert: Mo 12. Aug 2013, 18:17

Re: Der AVR-/ARDUINO-Faden

Beitrag von phettsack »

Wie wird das bei WLED gelöst, damit habe ich schon einige WS2812 mit angebunden und da flickert nichts. Oder ist mir nicht aufgefallen.
Benutzeravatar
Später Gast
Beiträge: 1699
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

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 :mrgreen:
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

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
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Fritzler hat geschrieben: Do 18. Mär 2021, 15:14 Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja :lol:
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
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.

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...
Dateianhänge
IMG_20210322_011558_copy_1612x1209.jpg
IMG_20210322_011607_copy_1612x1209.jpg
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.
jodurino
Beiträge: 2106
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

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
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

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?
Benutzeravatar
Hightech
Beiträge: 11474
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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

Code: Alles auswählen

for (uint8_t i = 0; i < 8; i++) {
    Serial.print(deviceAddress[i], HEX);
    }
mache, wird es in der Seriellen Konsole prima angezeigt

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();

}
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

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
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

snprintf!
https://www.cplusplus.com/reference/cstdio/snprintf/

Wer sprintf nutzt hat Hiebe mit der Lankabelpeitsche verdient :twisted:
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Natürlich, wenn, dann richtig (und sicher). Ich geh dann mal in meinen Folterkeller :lol:
Benutzeravatar
Hightech
Beiträge: 11474
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Ich will ja nicht den Kram auf der Seriellen Schnittstelle ausgeben das geht ja.
Benutzeravatar
sukram
Beiträge: 3114
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Mit den s(n)printf baust du in erster Linie einen String zusammen. Den kannst du dann wieder nach belieben weiterverwursten...
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

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 :twisted:
Wer gaaaaaanz genau weiss, was er tut, kann natürlich sprintf() benutzen. Abertausende von C-Programmier haben das tagtäglich gemacht.
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().
Benutzeravatar
Hightech
Beiträge: 11474
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

Hightech hat geschrieben: Di 6. Apr 2021, 11:43 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.
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.
Benutzeravatar
Finger
Administrator
Beiträge: 7465
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

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?
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

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.
Benutzeravatar
Zabex
Beiträge: 633
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Zabex »

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.
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.

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);
}
Der Code ist nur runtergeschrieben und nicht ausprobiert!

Gruß,
Zabex
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

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:

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 );
    }
     
   
}
Jetzt will ich noch über einen Wahlschalter entscheiden ob links oder recht rum gedreht wird.
Benutzeravatar
Hightech
Beiträge: 11474
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

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
ch_ris
Beiträge: 3042
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

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 :lol:
Benutzeravatar
video6
Beiträge: 6796
Registriert: Mi 23. Sep 2015, 09:18
Wohnort: Laage bei Rostock

Re: Der AVR-/ARDUINO-Faden

Beitrag von video6 »

Für Schachcomputer würde ich eine Hallmatrix nehmen.
Dann ist die Erkennung der Figur automatisch.
ch_ris
Beiträge: 3042
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ä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.
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

ch_ris hat geschrieben: Mi 14. Apr 2021, 06:55 Ziel ist ein Schach Computer.
AVR treibt "nur" das Schachbrett.
dabei soll er die Züge erfassen, also das Brett als Interface dienen ...
Bitte nicht schon wieder das Schnapsglas-Problem ...
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

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.
ch_ris
Beiträge: 3042
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

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.
Benutzeravatar
Hightech
Beiträge: 11474
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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
Antworten