ARDUINO am KNX

[rel]

Hmm, praktisch (nicht nur theoretisch!) können das dann aber auch Hanni&Nanni :-)

Makki

Und genau deswegen soll das iPhone 6 ins Spiel kommen: Nur nach Betätigung des Touch-ID-Sensors soll sich das iPhone über NFC mit dem RFID/NFC-Lesegerät verbinden und die Tür öffnen.

Ari

[tuxedo]

@Tuxedo: ich hab halt "keine Ahnung" von Programmieren... (das ist keine Ironie sondern Realität)

Weiß ich doch. War ja auch kein Vorwurf, sondern nur eine Feststellung.
Hab seit meiner Ausbildung auch nix mehr mit Mikrocontrollern gemacht. Seit dem bin ich nur in Hochsprachen auf "großen" Rechnern unterwegs. Und da ist man auch schnell verwöhnt.
Im Fall von Arduino verleitet es recht schnell da mit Libs und allerlei hilfreichem Zeugs (Strings...) zu arbeiten.
Für kleine Projekte mit überschaubarem Code (1-2 Seiten?!) ist das alles nicht tragisch.
Aber bei meinem 6Ch Dimmer wird es schon enger. Vor allem wenn noch so spielereien wie "parametrisierung über den Bus" hinzukommt.

Bzgl. sparen... Kommt drauf an. In meinem aktuellen Projekt sind es 7-9k die ich dadurch spare.
Durch die Macros bleibt's aber noch bedienbar/benutzbar.

b) wie knapp sind die resourcen wirklich (gibt es nicht Arudinos mit mehr speicher?)

Kommt drauf an und: Sicherlich. Der Due hat 512k ... Der Zero hat 256k. Ebenso der Mega 2560 ...
Aber keiner ist so schön klein wie der Micro.
32k (Leonardo, Micro, ...) sind eigentlich für das meiste auch genug. Man muss nur ein klein wenig Haushalten.
Und wer ganz verschwenderisch sein will: Raspi nehmen. Der ist ähnlich klein wie der Leonardo und hat quasi beliebig viel Speicher ... Bootet aber auch länger und hat die ganzen Tücken eines Betriebssystem mit an Board.



@makki

Deswegen kauft man auch bei Profis, zahlt 5€ mehr - und nicht beim billigsten Mr.Wong

Was nicht heisst, dass der Profi nicht günstig einkauft, umverpackt und für 5EUR mehr wieder verkauft... Von irgendwas wird der auch leben wollen.

Der Preis alleine ist heute keine Garantie mehr. Häuslebauer die Preise vergleichen werden das wissen (mein Lieblingsbeispiel: Dunstabzugshaube... Unser Modell bekommst du bei einer namhaften Schweizer Firma für rund 3500EUR als 'schweizer Design' Gerät, oder aber bei einem günstigen Onlineshop in Deutschland für rund 1100EUR. Ein und dasselbe Gerät. Nur mit anderem Namen und anderem Aufkleber drauf. In jedem Fall kommt das Ding aus Italien und kostet da in der Herstellung sicherlich nur 1/3 des günstigsten Onlineshop-Preises).

[makki]

@Rel: NFC und RFID sind sich sehr sehr ähnlich. Zumindest kann ich mit meiner "Visa Paywave" meine Haustüre öffnen (nicht nur theoretisch sondern auch praktisch).

Hmm, praktisch (nicht nur theoretisch!) können das dann aber auch Hanni&Nanni :-)

Makki

[makki]

Vielleicht nicht ganz uninteressant für die Leute hier, die mit Arduino experimentieren. FTDI liefert per Windows Update einen neuen Treiber für deren Chip, der geklonte Chips und damit den ganzen Arduino (?) unbrauchbar macht.

Nö, der Arduino hat(te) nen original FTDI und beim Rest (von eBay oder Mr. Wong) ist es doch nur hilfreich, wenn der gleich abgeschaltet wird, bevor man sich tagelang mit minderwertiger HW rumschlägt?!
Bewusst oder unbewusst Klone zu kaufen ist unterm Strich teurer (Zeit).

Bei der Kommunikation mit dem Chip sendet der neue Treiber ein bestimmtes Kommando, das von originalen Chips einfach ignoriert wird, geklonte Chips aber zerstört.

Es ist etwas anders, passt hier aber nicht rein.

Das Problem ist, dass selbst die Verkäufer oft nicht wissen, ob ein geklonter FTDI Chip auf dem Board ist oder nicht.

Deswegen kauft man auch bei Profis, zahlt 5€ mehr - und nicht beim billigsten Mr.Wong

a) was spart man wirklich (vergleich eines kompilierten Programms)
b) wie knapp sind die resourcen wirklich (gibt es nicht Arudinos mit mehr speicher?)

Naja, das ist schon ziemlich relevant;
Das ist kein Core-i7, wo man (Regel!) halt dem AW empfiehlt 8 statt 4GB RAM reinzustecken, weil man schlicht keine Lust hat, effizient zu programmieren - sondern der Entwickler sein Gehirn 100% hochfahren muss, um einfach nichts zu verschwenden
Ist altmodisch, aber wenn man mit AVR operiert, hilft es durchaus.. (und beim Rest würde es auch helfen, dann würde einiges auch noch aufm Pentium-1 mit 256MB laufen..)

Makki

[ThorstenGehrig]

Hi,
wow - ging ja einiges hier vorran... hatte beruflich viel um die Ohren und habe übersehen das es hier weiterging.

@Tuxedo: ich hab halt "keine Ahnung" von Programmieren... (das ist keine Ironie sondern Realität) und bin froh wenn ich überhaupt sowas wie String-Umsetzungen hinbekomme. Über die "Verschwendung" war ich mir garnicht klar. Bevor ich die Library Umstelle (ein fork ist ja jederzeit möglich) würde ich schon gerne verstehen
a) was spart man wirklich (vergleich eines kompilierten Programms)
b) wie knapp sind die resourcen wirklich (gibt es nicht Arudinos mit mehr speicher?)
Davpn abgesehen hört sich die "Macro-Variante" ja nicht schlecht an.

@Rel: NFC und RFID sind sich sehr sehr ähnlich. Zumindest kann ich mit meiner "Visa Paywave" meine Haustüre öffnen (nicht nur theoretisch sondern auch praktisch).
Daher vermute ich mal das ich mit dem iPhone das auch schaffe (ein 6 und ein 6+ habe ich schon hier) - allerdings: von "alleine" Sendet das iPhone nichts :-(
Und eine Kreditkarte kann man nicht einfach hinzufügen - ich komme zwar an das Menü (wenn man auf Englisch umstellt) - aber habe keine passende Kreditkarte...
Dazu hat Apple, soweit ich weiß, die NFC/RFID Schnittstelle noch nicht für andere Zwecke freigegeben.
Ergo => erstmal abwarten.
Ich vermute sobald ich eine passende Kreditkarte habe geht das.

Gruß
Thorsten

[rel]

Vielleicht weiß Thorsten mehr???

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?!

[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]

NFC ist doch nicht RFID, oder?

[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]

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

[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]

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.

[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]

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.