Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Okay - also statt des Strings "4/7/1" machst du das als Bytes... nur wo machst du die Übergabe/Umwandlung? Direkt im code? Also kein einfacher "Menschenlöslicher code" mehr?
Ich hatte das ja extra umgestellt auf "KNX-übliche Schreibweise"... vorher war das 3 x integer...
Nach aussen hin würde ich beides anbieten. String und byte. Intern aber nur mit byte arbeiten um RAM zu sparen.
[update]
Nur damit wir nicht aneinander vorbei reden:
1) Die Arduino KNX Lib arbeitet intern nicht überall "ram-sparend". Da kann man noch ein wenig optimieren
2) Wenn man mit vielen GAs arbeitet bzw. arbeiten muss, dann ist es hinderlich wenn man diese vielen GAs in String-Variablen im Speicher hält. Das verbrät unnötig viel RAM. Wie ich schon schrieb: Ich brauch ca. 50 GAs... Reduziert auf 2bytes pro GA wären dann "nur" 100 byte RAM. Hab noch nicth ganz rausgefunden wieviel ein String pro Zeichen verbrät. Aber nehmen wir mal an pro Zeichen ist es 1 byte. Dann haben wir alleine für die "/" schon 2 byte pro GA verbraten. Und dann kommen noch mindestens 3 weitere byte für eine durchweg einstellige Adresse dazu. Macht schon 5 Byte in Summe. Vom Overhead der Klasse "String" ganz zu schweigen. Bei 50 GAs wären wir da schon bei mindestens 250Bytes (2,5x mehr als unbedingt nötig).
3) Die API soll auf für "Anfänger" benutzbar bleiben. Alles auf kryptische 2 bytes umbiegen ist da eher hinderlich
Ergo: Ich werde schauen dass ich intern in der KNX Lib alles auf 2 byte GA ändere und nach außen zwei Varianten anbiete:
* Getter und Setter für 2-byte GA Schreibweise
* Getter und Setter für String GA Schreibweise
Wer eine kleine Anwendung schreibt der kommt ggf. mit dem String prima klar und benutzt die "Advanced" Version mit 2 bytes GA gar nicht. Der Compiler lässt das dann einfach weg.
Wer mehr braucht benutzt die Advanved Version und lässt die Sache mit dem String weg.
Vorteil: In jedem Fall wird RAM zumindest seitens der KNX Lib gespart. Wer dann selbst verschwenderisch mit Strings umgeht kann dies natürlich tun, oder es sein lassen.
-----
Noch ist der Umbau nicht so weit. Noch lese ich bei jedem eingehenden Telegram alle GAs vom EEPROM, wandle diese in String und checke damit ob das eingehende Telegram für welchen Kanal von Interesse ist. Aber bei jedem eingehenden Telegram bis zu 50GAs as dem EEPROM lesen und hin und her wandeln (Erst von bytes aus dem EEPROM in String und in der KNX LIb dann wieder zurück in 3x Integer) kostet unnötig Zeit und RAM.
Puuh, hab mal alles was ich so auf die schnelle gefunden hab von "int" auf "byte" umgebaut und hab 3 Hilfsmethoden eingebaut um von String-Gruppenadressen auf die interne 2-byte Repräsentation zu konvertieren, sowie zurück von 2-byte zu String.
Und noch eine um von 3x Integer auf 2-byte zu kommen.
Diverse andere Methoden in KnxTpUart und KnxTelegram hab ich von "int" auf "byte" reduziert.
Mein Beispiel-Programm ist damit "leider" von 22.262 bytes auf 22.490 bytes gewachsen. Dafür sollte sich der RAM-verbrauch sichtlich gesenkt haben.
Ein weiterer "unschöner" Haken dabei:
"int" liest sich schöner als "byte". Aber byte trifft es eben besser (0..255) als int (-32,768 .. 32,767).
Werde mal noch ein wenig damit herumexperimentieren...
ändern sich Deine Strings?
Falls nicht (und Du diese Methode noch nicht kennst), dann kannst Du verhindern, dass diese automatisch ins RAM geladen werden: <avr/pgmspace.h>: Program Space Utilities
Und hier mit ein paar Beispielen: Arduino - PROGMEM
Nachteil: Du musst Deine Funktionen, welche die Strings lesen, leicht umschreiben.
Wenn der String direkt einer Funktion als Parameter übergeben wird, kannst Du auch das Makro "F()" benutzen, also:
Code:
Serial.println(F("This string will be stored in flash memory"));
Das ganze ist noch hoch experimentell. Sobald ich es mit einem Prototyp sauber testen konnte gibt's den Code dazu.
@keil
Den "Trick" kenne ich schon. Hilft aber nicht. Denn die Strings um die es hier geht sind die Gruppen-Adressen auf die gelauscht werden soll. Und diese GA will ich nicht hard-codieren, sondern von außen Einstellbar machen. Also kann ich sie nicht im Flash hinterlegen.
Beim Start werden die Adressen aus dem EEPROM gelesen und im Speicher gehalten damit, wenn ein Telegram eingeht, der Check ob das Telegram relevant ist, möglichst schnell geht.
Vorrübergehend lese ich die Adressen bei jedem eingehenden Telegram aus dem EEPROM um sie nur kurz im Speicher zu halten. Das geht auch. Aber jedesmal die Adresse vom EEPROM lesen kostet unnötig Zeit, was die Bedienung ein klein wenig träge macht.
Deshalb der Umbau auf 2-byte Adressen statt String-Adressen.
Was mir beim durchstöbern des Forums gerade auffällt:
Muss ich denn nicht - wenn ich meine Schaltung "irgendwie" mit dem 230V Netz verbinde - den Bus galvanisch entkoppeln? Sonst wäre ja SELV etc. im Eimer?!
In meinem Fall besteht diese Verbindung durch die Anbindung der 230VAC->12VDC Netzteile (Meanwell, LED Netzteil) an die MOSFETs, welche wiederum mit dem Arduino verbunden sind, welcher wiederum mit dem Koppler verbunden ist.
Wie hast du das bei deinem RFID Projekt gemacht? Hattest ja geschrieben dass der Reader zu viel Saft zieht um ihn direkt über den Koppler aus dem Bus zu versorgen?!
Muss ich denn nicht - wenn ich meine Schaltung "irgendwie" mit dem 230V Netz verbinde - den Bus galvanisch entkoppeln? Sonst wäre ja SELV etc. im Eimer?!
Ja, Du musst für eine Trennung sorgen die den durch die Arbeitsgruppe Isolationskoordination formulierten Anforderungen entspricht.
Reicht es wenn ich den hier im Forum viel genannten "Adum" zwischen Koppler und Arduino hänge
Nein, ein Baustein alleine macht das nicht, das ist sehr viel mehr dass man drumherum wissen muss. Dafür gibt es auch entsprechende Normen.
Ich will Euch wirklich nicht den Spaß verderben, aber bei sicherheitskritischen Anwendungen gibt es keinen Spielraum für verkürzte, pauschale oder oberflächliche Darstellungen in einem Forum.
Wäre nett wenn hier jemand sich nicht ganz so verweigert wie Stefan (sorry).
Nur weil Dir meine Antwort nicht gefällt habe ich mich verweigert?
Nur weil ich darauf hinweise, dass es nicht so einfach ist, 230 V von SELV zu trennen und auf jeden Fall komplizierter als dies in einem Forum zu vermitteln? Sollen wir Dir jetzt alle relevanten Normen hier abschreiben und fertig für Dich durchkauen?
Mal abgesehen davon, dass Deine Frage mit "irgendwie" verbunden nicht gerade besonders spezifiziert ist.
Sei bitte so nett und denk nochmal darüber nach welche Antwort man auf unpräzise Fragen zur Trennung von tödlicher Spannung einzig und alleine geben kann.
hättest du ausführlich antworten wollen, hättest du ggf. nach weiteren Details gefragt. Deine Kernaussage war aber unterm Strich: Finger weg von 230V.
Ich hab das als "verweigern" aufgefasst, ja.
Wenn das saubere Trennen zweier Schaltungen die mit RS232/TTL verbunden sind (um mehr geht es hier nicht, und wenn du den Thread verfolgt hättest wüsstest du das auch) immer eine Doktorarbeit bedürfte, dann gäbe es hier wohl eine wirkliche Marktlücke.
Und genau DAS kann ich mir nicht vorstellen. Und genau deshalb müsste es hier eine recht einfache und praktikable (und vor allem zulässige) Lösung geben die man ohne Doktorarbeit vermitteln kann.
Deine Kernaussage war aber unterm Strich: Finger weg von 230V.
Es gibt einen unausgesprochenen Konsens unter den Moderatoren, Fragen zu sicherheitskritischen Themen nicht zu beantworten. Insbesondere weil zwangsläufig durch das Medium etwas zu kurz kommt und dieses Forum weltweit offen ist.
Ich will Dir nicht zu nahe treten, aber es gilt eben auch die Vermutung, dass derjenige der Fragen muss keine Ahnung hat und dann helfen auch zwei drei pauschale Tipps nicht weiter, weil sie den Frager vielleicht nur in einer gefährlichen Sicherheit wiegen. Ist nicht offending gegen Dich, sondern Konsens.
Wenn das saubere Trennen zweier Schaltungen die mit RS232/TTL verbunden sind (um mehr geht es hier nicht, und wenn du den Thread verfolgt hättest wüsstest du das auch)
Ich verfolge den Thread durchaus, aber Dein "irgendwie mit 230 V verbunden" hat für mich den Kontext verändert.
Und genau deshalb müsste es hier eine recht einfache und praktikable (und vor allem zulässige) Lösung geben die man ohne Doktorarbeit vermitteln kann.
Hmm, immer wenn ich mich mit dem Thema beschäftige und "irgendwo" 230 V in der Nähe sind, komme ich in die Nähe dies sehr genau betrachten zu müssen. Das ist eine normale Ingenieurstätigkeit die manchesmal auch für eine Doktorarbeit reichen mag.
Mach doch einfach mal eine Zeichnung von der gesamten Schaltung, dann kann man alles einfacher beurteilen als wenn man es "irgendwie" erraten muss.
Wieso muss ich - du hast den Thread ja verfolgt - nochmal erklären dass der Arduino mit dem Koppler über RS232 kommuniziert. Im beschriebenen Link ist genau das gezeigt, inklusive "Schaltplan". Betrifft dort zwar den Raspi, aber ob jetzt Raspi oder Arduino oder PC sollte doch wurscht sein, oder?
Es gibt einen unausgesprochenen Konsens unter den Moderatoren, Fragen zu sicherheitskritischen Themen nicht zu beantworten.
Dann lass es ganz. Die aktuelle Diskussiuon bringt mich nicht weiter und scheint dich nur Nerven zu kosten.
Ich will Dir nicht zu nahe treten, aber es gilt eben auch die Vermutung, dass derjenige der Fragen muss keine Ahnung hat und dann helfen auch zwei drei pauschale Tipps nicht weiter, weil sie den Frager vielleicht nur in einer gefährlichen Sicherheit wiegen. Ist nicht offending gegen Dich, sondern Konsens.
D.h. ich sollte vor jeder Frage meinem kompletten Background und Lebenslauf posten?
Ich verfolge den Thread durchaus, aber Dein "irgendwie mit 230 V verbunden" hat für mich den Kontext verändert.
das "irgendwie" bezog auf den Umstand dass die Schaltung nicht "100% bus-powered" ist und über weitere Verbindung mit einem Netzteil mit 230V verbunden ist. Das mit dem Netzteil hatte ich aber glaub ich erwähnt?
Hmm, immer wenn ich mich mit dem Thema beschäftige und "irgendwo" 230 V in der Nähe sind, komme ich in die Nähe dies sehr genau betrachten zu müssen. Das ist eine normale Ingenieurstätigkeit die manchesmal auch für eine Doktorarbeit reichen mag.
Ich will dir jetzt nicht zu nahe treten. Aber: So genau scheinst du es nicht betrachtet zu haben. Denn hier geht es die ganze Zeit um die RS232 Verbindung die die zwei Welten "KNX" <-> "Schaltung die am 230V Netz hängt".
Mach doch einfach mal eine Zeichnung von der gesamten Schaltung, dann kann man alles einfacher beurteilen als wenn man es "irgendwie" erraten muss.
Wofür einen Schaltplan? *Argh*
Ich will doch nur ein Gerät das am KNX Bus hängt und das eine RS232 Schnittstelle hat, an ein anderes Gerät mit RS232 Schnittstelle hängen, welches aber über ein 230VAC->5VDC Netzteil versorgt wird.
Sprich: Es muss einen IC, eine Komponente, einen Adapter, ... geben der die Trennung beider mit RS232 verbundnen Welten sauber trennt.
Und für alle Nicht-Bastler erwarte ich dass es einen "fix und fertigen Steck-Adapter" mit 9PolSubD gibt den man zwischen die beiden "Geräte"steckt und fertig. Und da wäre dann die Frage: Was ist da drin in der Regel verbaut? Auch sowas wie der Adum1201?
Klar reicht das, damit hast Du den Bus und den Arduino galvanisch getrennt. -> ADUM1201
Danke für die Bestätigung (das bestätigt was ich im Datenblatt des Adums gefunden habe) und danke dass du dich von "irgendwie verbunden mit 230V" nicht hast in die irre führen lassen.
Und sorry dass ich deine Antwort erstmal "übersehen" hab. Die "andere" Diskussion hat deine Antwort irgendwie untergehen lassen :-)
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar