ARDUINO am KNX

[makki]

Ebay 121300299450 hilft.

Das ist OT aber muss sein: Das sieht nach einem billigen Klon von Onkel Won aus!
Denn das original sieht anders aus, ist sehr gut und nur zu empfehlen, kostet aber etwas mehr als 9.75€ ..
https://www.saleae.com/logic16?gclid...FWzHtAodszUAsw

Makki

[l0wside]

Ebay 121300299450 hilft.

[JuMi2006]

Der Arduino ist fest auf 3.3V bzw. 5V eingestellt. Die 3.3V Variante macht auch alles richtig sofern man sie an die Siemens-BCU via Optokoppler anschließt.
Es liegt also definitiv am Shield. Zwischen RX (Shield) und GND messe ich 0V und zwischen TX (Shield) und GND 3.3V. Ich werde wohl mal eine weitere Schnittstelle an den Knotenpunkt Shield/Arduino hängen und sehen was da passiert. Aber ich fürchte Ohne Logic-Analyzer wirds schwer. Falls jemand das notwendige Material hat kann ich das gern in einen Umschlag stecken (@greentux?).

Grüße

[Bernator]

Wie wird denn der clock beim arduino eingestellt? Evtl.liegt hier das problem da der 3.3V arduino mit 8mhz läuft und die 5v version mit 16? Dann stimmt die baudrate nicht....

[Bernator]

Der tpuart2 kann auch 3.3V......

[dreamy1]

Was für ein Shield meinst Du denn?

Ein 3,3V-Arduino an einem 5V-TPUART wird ohne Pegelwandler an RX und TX vermutlich nicht funzen. Vor allem der TX am Arduino, da Du mit dem 3,3V-High-Pegel unter dem benötigten 0,7*VCC-Threshold am TPUART bleibst. Der TPUART kriegt vom Sendeversuch also nix mit. Auf RX-Seite wird Dir ohne Schutzbeschaltung die interne Clamp-Diode nach VCC am Arduino durchbrennen. Da reicht als quick&dirty-Lösung aber ein strombegrenzender Widerstand.

[JuMi2006]

Es schient wirklich am Shield zu liegen. Mit Siemens-BCU und Optokoppler funktioniert es. So ein Mist - ... bei 5V klappts.

[wintermute]

...hat vielleicht jemand nen funktionierenden Ansatz?

Dein Code sieht gut aus - da gibts ja nun auch nicht viel was nicht passen koennte
Abgesehen von der Hardware - also moeglichen Problemen mit dem Shield: koennte es evtl sein, dass Debugging aktiviert ist und sich das mit der Kommunikation auf derselben Schnittstelle beisst?

gruesse

[dreamy1]

Oha, das Wort "Shield" habe ich überlesen...ich dachte da hängt die Siemens TPUART2 dran.

[JuMi2006]

Weder das eine noch das andere, ich steck morgen mal die Siemens BCU ran, vielleicht liegt's doch am Shield.

[dreamy1]

Ist außer dem BA noch was anderes an der seriellen Schnittstelle dran? LK dazwischen, der die Telegramme vom Arduino filtert? Blinkt die LED am Arduino im Sekundentakt?

[JuMi2006]

Ja das ist schon klar ... ich war nur zu faul das noch mal zu ändern ... damit man genau sieht wo es (keine) Unterschiede gibt.

[dreamy1]

Hmmm,

Du willst doch den Mini zum Laufen kriegen, in dem Code hast Du aber alles auf den Leonardo "gestellt" :-)

D.h. die "//" müssen in die Zeilen vom Leonardo hin und beim Mini entfallen.

Also so:

#include <KnxTelegram.h>
#include <KnxTpUart.h>

//KnxTpUart knx(&Serial1,15,15,20); //for Leonardo
KnxTpUart knx(&Serial,15,15,20); // for Pro Mini

void setup() {
//Serial1.begin(19200); //for Leonardo
Serial.begin(19200); // for Pro Mini
//UCSR1C = UCSR1C | B00100000; //for Leonardo - Even Parity
UCSR0C = UCSR0C | B00100000; // for Pro Mini
knx.uartReset();
knx.addListenGroupAddress(0,0,100);
}

void loop() {
knx.groupWriteBool(0,0,100,true);
delay(1000);
knx.groupWriteBool(0,0,100,false);
delay(1000);
}

[JuMi2006]

Nachdem nun endlich was funktionierendes zum programmieren des 3.3V Mini auftauchte bleibt dieser Stumm. Das Shield arbeitet bei 5V und mit dem Leonardo (Pro Micro) sehr gut, aber der Mini bleibt stumm.

Da ich heute keine Lust mehr habe noch den Optokoppler auszupacken hat vielleicht jemand nen funktionierenden Ansatz?

Das hier will jedenfalls nicht funktionieren oder sieht jemand den Fehler? Die Libraries sind die von bitbucket.

#include <KnxTelegram.h>
#include <KnxTpUart.h>

KnxTpUart knx(&Serial1,15,15,20); //for Leonardo
//KnxTpUart knx(&Serial,15,15,20); // for Pro Mini

void setup() {
  Serial1.begin(19200); //for Leonardo
  //Serial.begin(19200); // for Pro Mini
  UCSR1C = UCSR1C | B00100000; //for Leonardo - Even Parity
  //UCSR0C = UCSR0C | B00100000; // for Pro Mini
  knx.uartReset();
  knx.addListenGroupAddress(0,0,100);
}

void loop() {
  knx.groupWriteBool(0,0,100,true);
  delay(1000);
  knx.groupWriteBool(0,0,100,false);
  delay(1000);
}

[wintermute]

Ich spreche aber vom Mini und nicht vom Micro. Das mit dem Speicher ist natürlich ein Argument, aber vielleicht kann man da trotzdem was machen, so viele Varianten gibt es ja auch wieder nicht.
Ich schau mir das morgen mal an, mein Testcode ist schon etwas länger da er auf Mega und Leonardo (Pro Micro) ohne Anpassungen läuft.

Mein Fehler, ich meinte natuerlich "Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega328". Damit laesst es sich bei mir kompilieren. Und auch fuer den 168er, den Mega, den Leonardo und - wers braucht - selbst fuers Lilypad.

Eine (schon aeltere) Aenderung in der Lib war die Umstellung von HardwareSerial, USARTClass (oder was auch immer je nach Board reingeschrieben werden musste) auf die Parentclass Stream. Damit kompiliert es nun ohne Aenderungen fuer jedes Board - zumindest hoffe ich das
Ohne diese Aenderung hat es Probleme (vor allem) beim Leonardo gegeben und - was mich besonders gestoert hat - es gab keine Debug-Moeglichkeit auf der USB-Schnittstelle des Leonardo/Micro. Das funktioniert jetzt parallel zum Betrieb am Bus via Serial1 (Debug dann auf Serial).
Einzig musste ich eigentlich immer vorm Programmieren kurz resetten weil das mit der 1200baud-Auto-Reset-Geschichte aus irgendwelchen Gruenden bei mir ploetzlich nicht mehr funktioniert hat - ich glaube aber das lag am Board selber. Ich probiers die Tage mal mit nem anderen, das angesprochene hat es ja jetzt ohnehin hinter sich

gruesse