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.
die Library von ThorstenGehrig sollte eigentlich auf den von dir genannten Mikroprozessoren lauffähig sein. Ja, tuxedo war da etwas schneller.
Erfahrungen habe ich nur mit den 8bit Mikroprozessoren gesammelt, wie dem Arduino Uno, Arduino Mega, Arduino Pro Mini und dem ATmega328pb, sowie dem ATmega1284p.
Aber gerne freuen wir uns über Erfahrungsberichte von dir.
Debug-port-Ausgaben sind für den Arduino Due in der Library von ThorstenGehrig schon vorgesehen.
Mit freundlichen Grüßen
Mag Gyver
Zuletzt geändert von Mag Gyver; 07.02.2017, 19:13.
Danke Euch beiden! Die Debug-Ausgaben habe ich in der Lib gesehen, nur ob es schon jemand ausprobiert hat war mir unklar...dann werde ich mal wohl testen müssen :-)
Darf man fragen was du vor hast? Als eigentliches Team-Mitglied von KONNEKTING hüllst du dich zeitweilen sehr in schweigen, bzw. lässt dir alles aus der Nase ziehen :-(
Nicht alles was ich in meiner Freizeit mache, hat unmittelbar mit Konnekting zu tun :-)
Hintergrund ist einfach der:
Für Kleinstanwendungen wie z.B. eine Temperatur alle 60s auf den Bus zu schreiben, ist Konnekting einfach oversized. Für komplexere Applikationen mit mehreren KO's, die man dann auch noch regelmäßig ändern möchte, hat Konnekting natürlich nach wie vor riesige Vorteile und da stehe ich auch nach wie vor voll dahinter...aber es gibt halt auch Fälle, wo man mit zwei Zeilen extra Code im Arduino-Sketch bereits am Ziel ist...
Gibt es denn noch Interesse daran die Lib möglichst funktionsfähig zu machen?
Ich sehe es nämlich genauso dass KONNEKTING zwar cool ist aber für eine Kleinigkeit einfach oversized (zumindest für mich). Daher wäre eine gut funktionierende Lib ohne Software-Overhead eigentlich ganz schön. Das kann sehr gut neben KONNEKTING existieren.
Ich bin vielleicht etwas "befangen" in meiner Meinung, aber:
Ich verstehe dass KONNEKTING einen gewissen Mehr-Aufwand mit sich bringt. Aber der Mehr-Aufwand bringt ja auch einen Mehr-Wert mit sich.
Wenn man z.B. Eugen's UUPS oder MI Schnittstelle nimmt, hat man ein 5min einen Temperatursensor aufgebaut und in in weiteren 20min den Sketch und die XML dafür fertiggestellt. Dann ist das ganze ne runde Sache und man muss in 5 Jahren, wenn doch mal ne Änderung der GAs ansteht, versuchen den Source mit der neuen GA zu compilieren und zu flashen. Suite öffnen, GA ändern, ein klick, fertig programmiert.
Der KONNEKTING Sketch ist nicht so viel länger, und die notwendige XML... Bei nur einem Temperatursensor ist die auch super klein.
Vielleicht mag mich ja mal jemand aufklären wo das Problem genau liegt... Liegts an den zusätzlichen Minuten die mal für die XML braucht? Oder ist es einfach nur zu "undurchsichtig"?
Ich mache es mal ganz knapp und bitte fasse es nicht als beleidigend auf:
1. Dein "Mehrwert" interessiert mich nicht. (Ich habe weder PA noch GA von meinem Arduino Schlüsselbrett in den letzten 2 Jahren geändert)
2. Wer sagt mir dass es in 5 Jahren noch KONNEKTING gibt? (Arduino IDE wird es mit deutlich höherer Sicherheit geben)
3. Ich will keine Suite downloaden, XML erstellen oder mich da einlesen. Ganz ehrlich, wer da neu ist versteht nur Bahnhof (Suite, DeviceLib, etc.)
4. Ich will keine Funktion "von der Stange" ... es geht um absolute Sonderlösungen (ich lese die Funktelegramme meines BBQ-Thermometers aus) - Prototyping
Also was ist nochmal das Problem dass neben KONNEKTING eine vernünftige Lib für einfachste Ansprüche existiert?
Nö, passt schon. Ich darf's aber kommentieren, oder?
1. Dein "Mehrwert" interessiert mich nicht.
Das ist ne Ansage. Aber auch Ansichtssache.
2. Wer sagt mir dass es in 5 Jahren noch KONNEKTING gibt? (Arduino IDE wird es mit deutlich höherer Sicherheit geben)
Und wenn es KONNEKTING in 5 jahren nicht mehr gibt, so gibt es JETZT die Suite. Die kann man sich runterladen, und die funktioniert auch in 5 Jahren noch. Das istd as tolle an Nicht-Cloud-Software. So richtig Old-School. Anschaffem haben und behalten und nutzen solange die Hardware es noch unterstützt.
3. Ich will keine Suite downloaden, XML erstellen oder mich da einlesen. Ganz ehrlich, wer da neu ist versteht nur Bahnhof (Suite, DeviceLib, etc.)
Das ergibt sich aus Punkt 1. Wer den Mehrwert partout nicht haben will, der will sich damit - vollkommen logisch eigentlich - damit auch nicht beschäftigen.
4. Ich will keine Funktion "von der Stange" ... es geht um absolute Sonderlösungen (ich lese die Funktelegramme meines BBQ-Thermometers aus) - Prototyping
Dann hast du KONNEKTING und oder Eugens UUPS leider nicht verstanden. Es geht ja absolut nicht um Funktionen von der Stange. Eugen's UUPS ist ein 32u4 mit eingebautem KNX Transceiver und alled möglichen IOs herausgeführt. Quasi ein "KNX Arduino". Einziger Unterschied zum "selbstbau Arduino und Siemens BCU": Das Ding ist kleiner, fast fertig aufgebaut, hat ne LED und nen Taster an Board (den man mit KONNEKTING zum programmieren nehmen kann) und kann auch OHNE KONNEKTING genutzt werden.
Also was ist nochmal das Problem dass neben KONNEKTING eine vernünftige Lib für einfachste Ansprüche existiert?
Im Prinzip nix Großes. Soweit ich es sehe gibt es momentan zwei Libs.
Die erste ist die von Thorsten gefundene und ein wenig aufgebohrte. Auf dieser beruht die zweite die ich mit tuxedo mal überarbeiten wollte was aber irgendwie nie dazu kam. Da hab ich auch mit persönlichem Zeitmangel Schuld dran.
In der zweiten wurde auf Bytes bei der GA/PA umgestellt und das Verwenden von Strings als Adresse ermöglicht. Es fehlen aber immer noch ein paar wichtige DPTs und was mir noch mehr Sorgen macht ist dass ich Probleme mit den GAs habe.
Hier bin ich nicht sicher ob es sich um Designfehler in der Lib oder in meinem Sketch handelt, wobei ich eher die Lib im Verdacht habe.
Entweder gehen Telegramme gar nicht raus (betrifft 2ByteFloat) oder gehen an falsche GAs (auch nicht optimal). Ein paar Funktionen laufen auch so noch ins Leere so dass man das mal ganz geordnet anpacken muss. Ehrlich gesagt fehlt mir hierzu allein aber die Zeit und Muse. Ein Programmier-Workaholic passt jedenfalls nicht zu mir falls es darum geht etwas zusammen zu machen. Da braucht es eher geduldige Partner die auch mal was ne Woche liegen lassen.
Sinnvoll wäre es das ganze offen in github zu entwickeln und da auch die Bugs zu sammeln. Das wird sicherlich auch lange dauern.
In kurz: Eigentlich kein konkret höheres Ziel, nur die vorhandene Lib auf Fehler kontrollieren und vollständig machen. Ich vermute da noch irgendwo ein Problem mit Speicheradressierung/Pointern. Zum Ende des Frühjahrs hätte ich gern meinen Smoker stabil am Bus .
Der Sketch ist soweit komplett fertig, scheitert aber echt an einer Stelle mit der Lib.
Das was ich "damals" aus der Lib mitgenommen hab (das war da, als ich die Lib "aufbohren" wollte, so dass man die Geräte - wie jetzt KONNEKTING - über den Bus programmieren kann), war, dass das Timing in der Lib nicht der knüller ist. Mal konnte ich programmieren, dann kamen Telegramme mal wieder nicht alle so an wie sie sollten etc... Ich hab's dann irgendwann aufgegeben.
Und seit ich Franck Marini's Lib aufbohre weiß ich: Ein korrektes Timing ist alles. Wenn das nicht auf <1ms stimmt, klappt auf einmal gar nix mehr.
Alles in allem: Die Franck'sche Lib ist deutlich strukturierter und hat weniger "just make it work, somehow"-Feeling im Code. Wirkt alles zusammen genommen "weniger gebastelt" und mit "etwas mehr Plan".
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