ARDUINO am KNX

[wintermute]

3,3V ist in diesem Bereich definitiv Standard.

Naja, in dem Bereich schon, wenns um Arduinos geht wird das meiste fuer 5V beschrieben... ich musste nur an all die vielen Beispielschaltungen denken die dann evtl nicht mehr out-of-the-box uebernehmbar sind. Ich weiss allerdings auch nicht wirklich wie viele das ueberhaupt sind

Fuer meine Zwecke ist das egal, weil ich eigentlich jedesmal soviel Peripherie drankorke, dass die 300mW ohnehin nicht mehr reichen und ich die g/w 24V mitbenutze...
Was mich zu ner Frage fuehrt: gibts eigentlich einen fertigen Ersatz fuer den ADUM der nicht-SMD ist? Mir gehts dabei nicht um meine eigenen Sachen, sondern eher um Beispiele hier fuers Forum - SMD schreckt da ja auch oft vom Nachbau ab...
Nach Moeglichkeit irgendwas, was ich nicht erst ausprobieren muss, sondern von dem sicher ist, dass es funktioniert und einfach so in den Schaltplan gepackt werden kann?

gruesse :: Michael

[l0wside]

Mit 5V hat man halt bei vielen externen Bausteinen so seine Probleme, weil die nur 3,3V mögen. Die Hersteller von Levelshiftern müssen sich jedenfalls so schnell keine Gedanken über ihren Absatzmarkt machen.

Ersatz für den ADUM als DIP gibt es m.W. nur als Optokoppler. Beim ADUM verstehe ich das Problem aber nicht: der ist doch selbst für Grobmotoriker problemlos zu löten (Pitch dürfte 1,27mm sein).

Max

[tuxedo]

Glaube das wurde hier schon mal in den Raum geworfen, fand aber wenig beachtung:

Prototype PCBs of the Arduino TPUART Interface | Daniel's Blog

http://dka.web-republic.de/2012/01/c...ino-to-eibknx/

Hat sich das schon jemand angeschaut? Damit wäre der Aufbau kleiner...

Gut, SMD löten ist hier nicht soo einfach, aber nicht unmöglich. Was ich nocht nicht verstanden habe? Braucht man zwingend einen UART auf Arduino-Ebene um mit KNX sprechen zu können? Oder geht's auch ohne?

Stelle mir gerade einen 1 oder 2 Kanal PWM Dimmer, angetrieben von einem Arduino vor. Damit sich das ganze gut verstecken lässt (das Netzteil braucht ja auch seinen Platz), wäre ein Arduino Micro oder Mini 05 ganz schick.

Gruß
Alex

[JuMi2006]

Naja ich mache gerade sowas und will am Wochenende mal Prototypen-Boards bestellen. Soll dann genau auf einen Pro Micro passen und diesen natürlich auch mit Strom versorgen. Das ist zwar nichts für die SMD-Gegner und nicht die finale Version, zeigt aber wohin die Reise bei mir gehen soll. Das ganze dann mit 5V wegen der Einbindung des 2482-100 mit I2C (wäre ein separates Shield). Programmierung dann hoffentlich ganz einfach über die vorhandene USB-Schnittstelle des Micro.

Wünschenswert wäre wenn man sich bei der KNX-Implementierung auf einen "Standard" mit Max und Robert einigen könnte. Die beiden hatten auch die TPUART2 schon als Eagle Library was das Leben einfacher gemacht hat . Aber erstmal muss das generell laufen.

Grüße

[Tessi]

Entschuldige meine direkte Art, aber ich glaube du verdienst nicht dein Geld damit.

Ja, das ist schon eine Weile her...

"Bit-Banging" heißt mitnichten, dass man mit Schleifen das Timing erzeugt bzw. Zyklen zählt.

Zu meiner Zeit verstand man darunter die Emulation einer normalerweise in entsprechenden Peripheriebausteinen enthaltenen Schnittstelle mit einfachen IO-Leitungen und entsprechender Softwareansteuerung. TIC-TOCs Konnte man nutzen sofern sie erstens vorhanden waren (OK, der AVR hat ein paar) und zweitens nicht schon anderweitig verwendet wurden (was leider meisten der Fall war). In vielen Fällen mussten da dann doch Warteschleifen und Polling eingesetzt werden, weil nichts anderes mehr verfügbar war.

Im konkreten Fall hast Du wohl recht, auch wenn es nicht 20MHz sondern "nur" 16MHz sind, reichen die 160 Takte wohl für die bis zu drei möglichen IRQs, sofern man in den ISRs tatsächlich nur das Notwendigste macht und den Rest asynchron außerhalb erledigen kann.

Nur wenn alle Modulprogrammierer sich auf die Timer stürzen, dann funktionieren deren Module wahrscheinlich auch nicht (zumindest nicht ohne nachträgliche Anpassung) zusammen im selben Projekt - aber genau das scheinen einige hier zu erwarten.

OK, wer nur 1-wire und TPUART verbinden möchte, hat noch kein Problem. Kommen aber weitere Schnittstellen dazu kann es schnell eng werden.

Das es so geht zeigen irrsinnig viele AVR-Projekte.

In denen aber wohl auch keine Anfänger werkeln...

Ja, ich glaube schon das 1-wire und TPUART mit einem AVR funktionierend bedient werden können, aber das muss jemand auch mit genau diesem Ziel entwickeln.
Und das wird hier ja nun in Angriff genommen.

[l0wside]

Naja ich mache gerade sowas und will am Wochenende mal Prototypen-Boards bestellen.

Dann bestelle mit ENIG und Kunststoff-Stencils, oder alternativ mit HASL und eine Blechschablone. Ersteres ist vermutlich die bessere Option.

Kurzkritik zu deinem PCB:

• Die Leitungsführung sollte Busklemme -> Transil-Leads -> Schaltung sein. Die Transil muss im Pfad liegen, weil sie diesen im Zweifelsfall schlicht kurzschließt. Wenn sie wie bei dir über dünne Leiterbahnen angeschlossen und in den Hinterhof verbannt wird, kann man sie fast schon weglassen.
• Der Quarz muss niederinduktiv (d.h. möglichst keine Vias), kurz und nach Möglichkeit mit symmetrischer Leiterbahnlänge an den TPUART angeschlossen werden. Wenn der Quarz quer draufpasst, nimm ihn nach oben und setze ihn zwischen Busklemme und TPUART. Unter dem Quarz keine durchgehende Massefläche vorsehen (eine eigene Massefläche, die an einem Punkt angebunden ist, ist aber ok).
• Deine Schaltreglerfläche ist ein bisschen groß geraten. Schau mal hier. Der Schaltregler ist die Störquelle #1, deswegen wird auch hier die Massefläche ausgespart.
• Die Abblockkondensatoren gehören möglichst nahe an die Versorgungspins. Ich würde an deiner Stelle versuchen, den TPUART mittig zwischen die beiden Pinreihen zu setzen und die Abblock-Kerkos entweder direkt daneben oder direkt darunter und dann über ein Via anzubinden. Auch hier ist der Weg: VCC -> Kerko-Pin -> TPUART-Pin. Das sieht vom Ansatz her bei dir schon sehr gut aus, nur sind die Leitungen für meinen Geschmack zu lang.
  Bei der Masseführung gibt es verschiedene Philosophien. Du fährst auch die Massepins jeweils über den Kerko an, das ist absolut ok. Alternativ geht auch der Ansatz "große Massefläche für alle". Aber selbst mein Brötchengeber ist sich da intern nicht einig, was denn nun besser ist...

Gruß,


Max

[idefix6]

Was haltet ihr davon, die Entwicklung eher in Richtung ARM zu gehen, von Arduino gibt es hier auch schon eine Platine (also ein Atmel ARM):
Arduino - ArduinoBoardDue

Diese Platform hätte gut Luft nach oben und der Prozessor braucht nicht mehr Strom.

[l0wside]

Was haltet ihr davon, die Entwicklung eher in Richtung ARM zu gehen, von Arduino gibt es hier auch schon eine Platine (also ein Atmel ARM):
Arduino - ArduinoBoardDue

Diese Platform hätte gut Luft nach oben und der Prozessor braucht nicht mehr Strom.

Dem TPUART ist´s im Prinzip egal. Er will an einem Pin die Interfacespannung angelegt bekommen, das sollte man vom Arduino irgendwo abgreifen können.

Wenn der Schaltregler den Arduino mit versorgen soll, braucht es auf dem Aufsteckboard eben einen Jumper für die Umschaltung 5V/3,3V. Mehr Aufwand sehe ich nicht.

Ansonsten: ein ARM ist in meinen Augen zwei Hausnummern zu groß, wenn nicht gerade z.B. ein Touchpanel dran soll.

Max

[idefix6]

ich sehe den ARM mit viel Potential.
Man hat jede Menge Timer drin (Stichwort Dimmer), viele serielle Schnittstellen (Ansteuerung fertiger externer Dimmer).
Er hat viel mehr Speicher, kann atomaren Operationen (was vielen Problemen vorbeugt) und er hat mehr Speicher (was gerade bei Displayansteuerung hilfreich ist), SPIs (für einfache Ansteuerung von Bitschiftern für das multiplexen von IOs) und viele andere Sachen.

Er liegt preislich auf dem gleichen Level wie der Atmega644.
Ich würde einen SAM4 von Atmel ins Auge fassen (die 48pin Variante).

Da es ja schon ein Board von Arduino gibt, sollte hier doch die Unterstützung auch nicht schlecht aussehen oder?

[keldan2]

Ja - Wirkbetrieb seit dem Wochenende zu vollster Zufriedenheit :-)
Ich habe ja "schon immer" einen 125kHz RFID-Leser - bisher von RSS per RS485 an Wiregate. Diese Anbindung war aber nicht immer 100%ig - das neue Projekt ist jezt viel Besser.

Gruß
Thorsten

Hey Thorsten,

ich habe gerade am WE ne T25 aufgebaut - siehe Facebook (hab dich gerade mal geaddet).

Dieses Projekt war die allererste Berührung mit der Mobotix T25, und ich muss schon sagen, gewaltig und überzeugend.

Nun bin ich wieder am schwanken zwischen einer "Selbstbaulösung RFID", ekey, etc. oder direkt T24 mit Keypad und RFID.

Somit hätte ich die Lösung wenn ich mal keine RFID Karte am Mann habe, auch per Tastencode die Tür zu öffnen-> das was du sagst -> per RFID am Schlüsselbund geht schneller als Fingerprint, sehe ich auch so bei meinem Conrad Reader.

Ich weiss ja das du die T24 selbst im Einsatz hast. Nutzt du hier kein RFID ?? Gehen dort auch andere RFID TAGS - kleinere hinter der Uhr, am Schlüsselbund etc.
Hast du die T24 incl.Video/Gegensprechen,Tür öffnen, etc.in deiner genialen XXAPI Lösung.

Mann (Ich) habe so viele Baustellen, und dieses Arduino ist glaube ich ne Nummer zu hoch für mich.

LG und Sorry für OT, aber es passte gerade hier rein - bez. der Baustelle am WE.

Daniel

[ThorstenGehrig]

Hi Keldan,
hab mal nicht soviel Angst vor dem Arduino. Das ist ist echt einfach - die größte herausforderung ist das "Einbauen" in eine passende Halterung!

Die Mobotix-RFID-Lösung habe ich nie angeschaut - die gab es am Anfang noch nicht - und ich Vermute mal das Sie viel teurer ist UND die Konfiguration der T24/T25 ist eher ein "krampf".
Mit der Arduino-Lösung hast du es direkt auf dem Bus - so will man es haben :-)
Per "Tastencode" finde ich eher "basic". Fingerprint ist natürlich "teurer Luxus" - der mich persönlich aber schon überzeugt. Früher hätte ich nie gedacht das die Teile so zuverlässig sind.

Vorschlag zum Arduino: schreib mich mal per PM an - und lass uns mal telefonieren.

Gruß
Thorsten

[JuMi2006]

Ich spiele schon eine Weile rum, heute nen Tag frei und der Micro ist gekommen, also erstmal getestet. Programmiert als "Leonardo".

Mit "Blink" zieht der Micro 40mA aus der BCU und ist damit in den Specs - super !!!

Also wollte ich mal die KNX-Anbindung machen:

#include <KnxTpUart.h>

// Initialize the KNX TP-UART library on the Serial1 port of Arduino Mega
KnxTpUart knx(&Serial, 15, 15, 20);

void setup() {
  Serial.begin(19200);
  UCSR1C = UCSR1C | B00100000; // Even Parity
  knx.uartReset();
}

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

Allerdings gibt mir das Fehler:

knxtelegramm_micro:4: error: no matching function for call to 'KnxTpUart::KnxTpUart(Serial_*, int, int, int)'
/Users/mko/Dropbox/Arduino/libraries/KNX/KnxTpUart.h:40: note: candidates are: KnxTpUart::KnxTpUart(HardwareSerial*, int, int, int)
/Users/mko/Dropbox/Arduino/libraries/KNX/KnxTpUart.h:38: note: KnxTpUart::KnxTpUart(const KnxTpUart&)

Mit

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

kommt der Fehler nicht, aber es passiert auch nix am Bus (was ich wiederum verstehe).

Die KnxTpUart.h sieht folgendermaßen aus:

#ifndef KnxTpUart_h
#define KnxTpUart_h

#include "HardwareSerial.h"
#include "Arduino.h"

#include "KnxTelegram.h"

// Services from TPUART
#define TPUART_RESET_INDICATION_BYTE B11

// Services to TPUART
#define TPUART_DATA_START_CONTINUE B10000000
#define TPUART_DATA_END B01000000

// Debugging
// Für UNO muss TPUART_DEBUG auf false

#define TPUART_DEBUG false
#define TPUART_DEBUG_PORT Serial

// Für UNO muss TPUART_SERIAL_CLASS HardwareSerial (war mal für Mega USARTClass)
#define TPUART_SERIAL_CLASS HardwareSerial

// Timeout for reading a byte from TPUART
#define SERIAL_READ_TIMEOUT_MS 10

// Maximum number of group addresses that can be listened on
#define MAX_LISTEN_GROUP_ADDRESSES 15

enum KnxTpUartSerialEventType {
	TPUART_RESET_INDICATION,
	KNX_TELEGRAM,
	IRRELEVANT_KNX_TELEGRAM,
	UNKNOWN
};

class KnxTpUart {
public:
	KnxTpUart(TPUART_SERIAL_CLASS*, int, int, int);
	void uartReset();
	void uartStateRequest();
	KnxTpUartSerialEventType serialEvent();
	KnxTelegram* getReceivedTelegram();
	
    void setIndividualAddress(int, int, int);
    
	void sendAck();
	void sendNotAddressed();
	
	bool groupWriteBool(int, int, int, bool);
	bool groupWrite2ByteFloat(int, int, int, float);
	bool groupWrite1ByteInt(int, int, int, int);
	bool groupWrite2ByteInt(int, int, int, int);
	bool groupWrite4ByteFloat(int, int, int, float);
    bool groupWrite14ByteText(int, int, int, String);

	bool groupAnswerBool(int, int, int, bool);
	bool groupAnswer2ByteFloat(int, int, int, float);
	bool groupAnswer1ByteInt(int, int, int, int);
	bool groupAnswer2ByteInt(int, int, int, int);
	bool groupAnswer4ByteFloat(int, int, int, float);
    bool groupAnswer14ByteText(int, int, int, String);


	void addListenGroupAddress(int, int, int);
	bool isListeningToGroupAddress(int, int, int);
    
    bool individualAnswerAddress();
    bool individualAnswerMaskVersion(int, int, int);
    bool individualAnswerAuth(int, int, int, int, int);
    
    void setListenToBroadcasts(bool);
    
    
private:
	HardwareSerial* _serialport;
	KnxTelegram* _tg;       // for normal communication
    KnxTelegram* _tg_ptp;   // for PTP sequence confirmation
	int _source_area;
	int _source_line;
	int _source_member;
	int _listen_group_addresses[MAX_LISTEN_GROUP_ADDRESSES][3];
	int _listen_group_address_count;
    bool _listen_to_broadcasts;
	
	bool isKNXControlByte(int);
	void checkErrors();
	void printByte(int);
	bool readKNXTelegram();
	void createKNXMessageFrame(int, KnxCommandType, int, int, int, int);
	void createKNXMessageFrameIndividual(int, KnxCommandType, int, int, int, int);
	bool sendMessage();
    bool sendNCDPosConfirm(int, int, int, int);
	int serialRead();
};

#endif

Jemand nen Tip?

Grüße

[dreamy1]

Ich schätze mal, dass ein Konflikt bei den "Serial" vorliegt....der Micro dürfte nur eine serielle Schnittstelle haben. Dann darf im Code auch nirgends eine "Serial1" vorkommen (einige Arduinos haben mehrere Hardware-Serielle onboard, die sind dann "durchnumeriert").

Ersetze also mal alle Stellen mit "Serial1" durch "Serial"...auch in der .cpp...

[JuMi2006]

Alles klar, hab den entscheidenden Hinweis gefunden ... Also es bleibt hier wohl bei Serial1.

Heute Abend werde ich Ihn dann mal mit 4 Multisensoren und 2 DS18B20 bestücken und schauen was da an Strom fließt.

[dreamy1]

Alles klar, hab den entscheidenden Hinweis gefunden ... Also es bleibt hier wohl bei Serial1.

Na lass mal hören...wo genau lag denn der Fehler? Ich lerne da auch gerne dazu, zumal ich das Ganze noch auf einen Pro Mini portieren muss :-)