ARDUINO am KNX

[tuxedo]

Ist schon eine äußerst ärgerliche Sache. Bei den Arduinos kann man vllt. noch sicherstellen dass man ein "original" erwirbt. Aber es gibt ja so viel Hardware wo man es einfach nicht weiß. Hab hier sicher 3-4 USB-RS232 Adapter rumfahren... Da weiß kein Mensch was da drin verbaut ist...

Gerade noch was zum Thema "unbrick" gefunden:

zeroflow comments on Watch That Windows Update: FTDI Drivers Are Killing Fake Chips

[2ndsky]

Auf der Seite Virtual COM Port Drivers kann man auch alte Treiber runterladen. Rein vom Datum her sollte der Treiber mit der Versionsnummer 2.10.00 noch passen. Das Problem trat den Berichten zufolge erst mit Version 2.12.00 vom 29.09.2014 auf. Wenn ihr Windows verwendet, checkt die Treiberversion bei euch und installiert zur Not den alten Treiber. Ob es mit diesem geht, kann ich euch aber nicht versprechen. Ich übernehme keine Garantie und die Verwendung erfolgt auf eigene Gefahr!

[tuxedo]

Gerade eben gelesen:

Nachtrag vom 24. Oktober 2014, 10:55 Uhr

Laut Ars Technica hat Microsoft die beiden letzten Versionen des FTDI-Treibers aus dem Windows-Update entfernt.

[2ndsky]

Auch FTDI hat vor ner halben Stunde getwittert, dass sie den Treiber wohl zurück gezogen haben... war wohl doch keine so gute PR

[tuxedo]

Was für Vollpfosten. Hätte man sich ja denken können dass ein Großteil der Benutzer keinen Schimmer hat

1) dass da überhaupt so ein Chip verbaut ist
2) welcher exakte Typ verbaut ist

Ist ja kein spezieller Treiber nur für Entwickler und Bastler...

[bmx]

Hi Thorsten,

Projekt: ARDUINO-Schaltung an den KNX Bus

danke für Deine Idee und das Projekt. Ich habe hier jetzt eine Brötje mit PPS Schnittstelle soweit bekommen, das die mir Aussen-, Kessel- und Brennertemperatur auf den KNX meldet. Im nächsten Step will ich dann mal das Senden auf PPS probieren damit ich die Heizung vom KNX aus steuern kann. Also nochmals Danke!

Gruß,
Bernd

[tuxedo]

Nochmal ein kleines Feedback bzgl. der TPUart-Lib ...

Thorsten's Ansatz String zu verwenden um die Adresse "einfacher" im Programmcode zu verwursten war von der Idee her nicht schlecht. Aber das zieht einen großen Nachteil mit sich:

Speicherbedarf....

Alleine die Verwendung der String-Lib innerhalb der TPUart-Lib verschlingt ganze Kilobytes.

Hab angefangen von String wieder zurück auf 3xint umzubauen. Trotz vieler Debug-Zeilen ist mein Code von 17k auf aktuell knapp 13k geschrumpft.

Rund 4k für "1/1/1" statt 1, 1, 1. Und ich hab noch nicht alles zurückgebaut...

Für kleine Basteleien mag es zwar egal sein, aber rund 4k für eine nur leicht bessere Schreibweise... Find ich zu viel.

Werde weiter umbauen und optimieren und versuchen das Endergebnis noch gut nutzbar und einfach verständlich zu halten. Ergebnis wird dann irgendwann veröffentlicht wenn es in brauchbarem/vorzeigbarem Zustand angekommen ist.

[l0wside]

Hab angefangen von String wieder zurück auf 3xint umzubauen. Trotz vieler Debug-Zeilen ist mein Code von 17k auf aktuell knapp 13k geschrumpft.

Auf dem Bus ist das einfach nur 1xUint16. Warum nutzt du nicht das Format, in das spätestens beim Senden sowieso umgerechnet werden muss?

Max

[tuxedo]

Auf dem Bus ist das einfach nur 1xUint16. Warum nutzt du nicht das Format, in das spätestens beim Senden sowieso umgerechnet werden muss?

Max

Hab kein Problem mit der 2byte Darstellung. Aber für kleine Bastelprojekte wäre es einfacher etwas "lesbares" in den Code schreiben zu können.

Die Lib wurde initiell für 3x int gemacht. Dann hat Thorsten sie in großen Teilen auf API-Seite auf String umgebaut, was ich gerade wieder umkehre.
Int ist an sich auch noch zu groß. 3x byte wäre besser. Ist auch kein Aufwand das zu ändern.

Ob es aber wirklich viel spart wenn ich von "3 leserlichen bytes" auf "2 unleserliche bytes" umsteige bleibt dahingestellt. Geht hier auch nur um die länge des Programmcodes.
Die interne Liste mit "auf die zu laschenden GAs" hab ich schon auf die 2-byte Variante umgebaut. Das spart zur Laufzeit RAM.

[update]
Aus der Java-Welt kommend bin ich eben (wieder) auf Macros gestoßen... Denke mit deren Hilfe erschlägt man zwei Dinge:

1) Die Lib arbeitet intern mit 2-bytes statt mit 3 bytes, 3 int oder String
2) Die Verwendung der Lib bleibt auch für Anfänger verwendbar

Ein Beispiel:

Ursprüngliche Variante:

KnxTpUart knx(&Serial1, 15,15,20);

Thorstens Änderung:

KnxTpUart knx(&Serial1, "15.15.20");

Meine Änderung:

byte individualAddress[2] = {0xff, 0x14}; // ==> 15.15.20
KnxTpUart knx(&Serial1, individualAddress);

Mit Macros:

KnxTpUart knx(&Serial1, PA_TO_BYTES(15,15,20));

oder auch

KnxTpUart knx(&Serial1, PA_STRING_TO_BYTES("15.15.20"));

Die notwendigen Macros dahinter:

#define PA_TO_BYTES(area, line, member) (byte[]){(area << 4) | line, member}
#define PA_TO_BYTES(address) (byte[]){(String(address).substring(0, String(address).indexOf('.')).toInt() << 4) | String(address).substring(String(address).indexOf('.')+1, String(address).lastIndexOf('.')).toInt(), String(address).substring(String(address).lastIndexOf('.')+1,String(address).length()).toInt()}

Denke das ist ein guter Kompromiss (sofern man keine absolute Abneigung gegen Macros hat).

Wer dann nur ein kleines Projekt hat und seine Adressen "hardcodiert", der verwendet die Macros. Ansonsten wird mit 2 byte gearbeitet.

Ich verschwinde dann wieder hinter meiner Arduino IDE .... weitermachen.

[Steph]

Denke das ist ein guter Kompromiss (sofern man keine absolute Abneigung gegen Macros hat).

Genau dafür sind Makros doch da. Für mich perfekt gelöst!!

[tuxedo]

So, ich denke ich bin durch mit der Änderung.

Mal eben schnell einen Test-Sketch zum Größenvergleich gebastelt:

// für den KNX Zugriff
#include <KnxTelegram.h>
#include <KnxTpUart.h>

// Start with default PA
KnxTpUart knx(&Serial1, PA_INTEGER(15,15,20));

void setup() {
  
    // Setup serial port for KNX BTI
    Serial1.begin(19200);
    UCSR1C = UCSR1C | B00100000; // Even Parity
    knx.uartReset(); 
  
}

void loop() {
}

void serialEvent1() {

    // forward the event processing to KNX lib
    KnxTpUartSerialEventType knxEventType = knx.serialEvent();
    switch(knxEventType) {

      case KNX_TELEGRAM:     
          Serial.println("it's a KNX telegram...\n");          
          break;
  
      default:
          break;

    }
}

mit TpUart.h:

#define MAX_LISTEN_GROUP_ADDRESSES 48

Mit der "optimierten" Variante:

Binäre Sketchgröße: 10.602 Bytes (von einem Maximum von 28.672 Bytes)


Hab nur die Originale grad nicht mehr da. Vielleicht will ja jemand anderes Gegenvergleichen?!

Vermutlich hab ich weniger spart als ich vermute (wobei: Ich hatte vor der Änderung mit meinem Projekt zwischen 22 und 24k.. Jetzt sind's aktuell 15k .. Also 7-9k gespart). Aber

1) etwas gespart ist besser als überhaupt nicht gespart
2) die Verwendung ist ähnlich einfach geblieben
3) das lästige hin- und herrechnen der Adressformate kann jetzt entfallen

Jetzt heisst es: Hübsch machen ...

[rel]

Hi
hier mal eine kleine Projektdokumentation zu meinem RFID-Leser-Projekt.
Der Arduino-Code ist noch der selbe wie früher - mit minimalen änderungen.
Derzeit sende ich die Seriennummer einfach an den HS zum Auswerten - das erspart umprogrammieren wenn ich einen neuen Transponer habe - und ermöglicht zusätzliche Sicherheits-Logiken (da RFID ja als unsicher anzusehen ist).
PA und Gruppenadresse muss natürlich im Code noch angepasst werden.

Gruß
Thorsten

Hallo Thorsten und alle anderen,

ins neue iPhone 6 ist ja nun endlich NFC "eingezogen". Ist es denk- bzw. machbar, dieses als "Schlüssel" für die Tür zu nutzen?

"Eine weitere Überraschung ist der verbaute NFC-Chip. Apple hat sich nach Jahren endlich dazu bewegt, setzt den Chip aber zur Zeit nur für eine Funktion ein. Apple Pay. Der mobile Bezahldienst erlaubt das bargeldlose Bezahlen mit dem iPhone, kann aber zur Zeit nur in den USA verwendet wird. Aus diesem Grund bringt der NFC-Chip momentan noch keine weitere Funktionalität, was sich aber in Zukunft mit Sicherheit ändern wird."

Danke.

Ari

[tuxedo]

NFC ist doch nicht RFID, oder?

[rel]

Nur kurz geschaut:
"Near-Field-Communication oder auf Deutsch "Nahfeldkopplung", basiert auf der RFID Technologie und zeichnet sich durch ein spezielles Kopplungsverfahren aus, dass auf gesonderte Frequenzbereich genormt ist (135 kHz; 13,56 MHz nach ISO 18000-2, -3; 22536)."
Unterschied RFID und NFC - Eine kurze Erklärung - Fakir Informatik

Und? Kennt sich jemand aus? Geht das mit dem neuen iPhone 6?

Danke. Ari

[tuxedo]

Hmm, okay. Wenn ich mit den RFID reader von Throsten anschaue, dann steht da, dass der auch NFC kann.

Denke wenn de angebissene Fallobst NFC nach dem Standard anständig unterstützt, dann kann das klappen.

Zur not Weg vom Fallobst, hin zum Androiden?!