Hallo, ich möchte Fußbodenheizungsventile mit einem elektronischen Heizkörper Thermostat steuern. https://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate Ich möchte die Thermostat nicht allzu stark umbauen. Deshalb möchte ich die vorhandene Schnittstelle nutzen. Über eine USB Buchse sind VSS, VDD und 3 IO PINs (MISO, MOSI, SCK) herausgeführt. https://www.mikrocontroller.net/articles/Datei:THERMYV3-sch.jpg Ich benötige einen Temperatur Sensor, der die Rücklauftemperatur für den zu regelnden Kreis misst. Weiterhin eine BUS für den Datenaustausch, unter anderem für: - mehrere Heizkreise und somit Regler für einen Raum müssen untereinander abgestimmt werden - einem Gateway um von Zentraler Stelle Sollwertvorgaben machen zu können und statistische Daten zu erheben und zu speichern - ein Firmware update über den BUS mit Hilfe eines Bootladers Nach längerer Recherche hier im Forum bin ich auf die Idee gekommen einen Physikalischer CAN Bus mit Transceiver ohne Controller aufzubauen. Vereinfachtes Schema ist angehängt. Die CAN Transceiver bilden den Physikalischer CAN Bus mit all seinen Positiven Eigenschaften. Als Protokoll wird dann aber kein CAN gesprochen, da kein Controller vorhanden ist, sondern was serielles wahrscheinlich n x 8 Bit mit Prüfsumme und einem Sync Frame, außerdem wie bei CAN mit Rücklesen über den RXD zur Kollisionserkennung, und das ganze ganz langsam ------------------------------------------------ Ist dies möglich? Wo sind die Fallstricke - Denkfehler? ------------------------------------------------ Randnotizen: MISO, MOSI, SCK – toll ist doch seriell in Hardware => Leitung chip select und Interrupt fehlt 2 PIN soft seriell wie RS232 – einfach zu implementieren => kein Bus, TX und RX sind zu getauschen 1 PIN empfangen, 1PIN weiterleiten, im Ring – einfach => sehr störanfällig wenn Teilnehmer ausfällt RS585 – Treiber nutzbar, Multimaster fähig => Buszugriff muss selbst geregelt werden TOKEN? CAN – alles super => kein Controller integriert und mangels IO auch nicht anbindbar CAN Controller mit I2C in bezahlbar?
Angehängte Dateien:
-
schema.PNG
57 KB
Heinz-Wilhelm F. schrieb: > Nach längerer Recherche hier im Forum bin ich auf die Idee gekommen > einen Physikalischer CAN Bus mit Transceiver ohne Controller aufzubauen. > Vereinfachtes Schema ist angehängt. > Die CAN Transceiver bilden den Physikalischer CAN Bus mit all seinen > Positiven Eigenschaften. Das ist, wie wenn du sagst: "Die Reifen und die Radmuttern mit all ihren postiven Eigenschaften nehme ich vom Golf, aber das Auto dazu baue ich selber!" > Wo sind die Fallstricke - Denkfehler? Wie üblich wirst du die Denkfehler im Laufe der Entwicklung deines proprietären Busses finden. Meine Erfahrung: die Analyse und die Behebung dieser Fehler wird dich viel mehr Zeit, Nerven und Geld kosten, als die paar Cent, die du zahlen musst, wenn du einen Bus einsetzt, der seit 35 Jahren weltweit im Feld erprobt ist. > CAN Controller mit I2C in bezahlbar? Nimm doch einfach den MCP2515 und binde den per SPI an deine µC an, dann hast du nicht nur die Physik des CAN-Busses, sondern auch die Multimasterfähigkeit, die Arbitrierung, die Fehlererkennung, das Pakethandling, ... https://www.microchip.com/wwwproducts/en/en010406
:
Bearbeitet durch Moderator
CAN ohne CAN-Controller betreiben zu wollen heißt ganz einfach RS-485. Wobei ich ansonsten aber ganz Lothars Meinung bin. Falls in Wirklichkeit die Sorge um die Einarbeitung in CAN in dahinter stecken sollte: dank guter LIBs ist das recht einfach geworden. Vielleicht ein Saleae (Clone) kaufen, dann wird das Debugging recht einfach und man bekommt ein Gefühl für die Ereignisse auf dem Bus.
Harald schrieb: > CAN ohne CAN-Controller betreiben zu wollen heißt ganz einfach RS-485. Das ist nur die "halbe" Wahrheit, denn die Kollisionserkennung soll beim neu zu implementierenden Bussystem ja schon (per Software?) auf der rezessiven "1" basieren. auf einem RS485 ist eine Kollision auf Bitebene nicht so einfach zu erkennen. Da braucht es weitergehende Verfahren wie eine Parity-Information oder eine Prüfsumme für das Paket.
Heinz-Wilhelm F. schrieb: > Ich möchte die Thermostat nicht allzu stark umbauen. Mit entsprechendem Controller ist CAN so wunderbar einfach zu programmieren, dass es sich sogar lohnen könnte, einen CAN-fähigen Controller (z.B. STM32F103) einzubauen. Die gibt's auch super billig auf Breakout Board ("blue pill"). Nachricht per CAN übertragen: Nachricht in Register schreiben und wieder auslesen. Fertig. Hardware sorgt dafür dass sie intakt ankommt. Nachricht per UART senden: Jedes Byte einzeln nacheinander ins Senderegister schreiben. CRC berechnen. Jedes Byte einzeln empfangen. CRC prüfen. Nachrichten Anfang erkennen. Ggf . Neuversand einleiten. NRZ-Kodierung implementieren. Paketlänge erkennen. Automatisches zurück setzen der State Machine bei Übertragungsfehlern. Timeouts erkennen. usw... Das Nachrichten Format muss dem der CAN Frames ähneln, weil die Fehler Erkennung der Transceiver sonst zuschlägt. Nebenher ist CAN Multi Master Fähig, du kannst später simpelst neue Teilnehmer einfügen ohne die vorhandenen zu modifizieren.
Heinz-Wilhelm F. schrieb: > CAN Controller mit I2C in bezahlbar? Vielleicht solltest du etwas ausführlicher beschreiben, weshalb zwar ein Mega16 möglich (oder schon vorhanden?), aber volles CAN nicht einsetzbar ist und auch kein MCP2515 dran passt. Aber zu Not ist auch ein zusätzlicher µC als I2C/CAN Konverter möglich.
:
Bearbeitet durch User
A. K. schrieb: > und auch kein MCP2515 dran Wenn es sich nicht um eine Erweiterung eines schon vorhandenen Systems handelt, würde ich den auch nicht nehmen. Ein Controller mit integriertem CAN kostet auch nicht viel mehr als der MCP2515 und ist meiner Meinung nach einfacher zu programmieren. (z.B PIC18F25F83, MCP2515 bei Mouser ~gleicher Preis bei kleinen Stückzahlen)
:
Bearbeitet durch User
Heinz-Wilhelm F. schrieb: > Nach längerer Recherche hier im Forum bin ich auf die Idee gekommen > einen Physikalischer CAN Bus mit Transceiver ohne Controller aufzubauen. > Vereinfachtes Schema ist angehängt. Im Gegensatz zu den Vorrednern sage ich: Mache es! Da Du keine hohe Übertragungsrate brauchst, reicht im einfachsten Fall ein kleiner 8-pol. µC (ATtinyxx) aus, um am Busverkehr teilzunehmen.
Volker S. schrieb: > Wenn es sich nicht um eine Erweiterung eines schon vorhandenen Systems > handelt, würde ich den auch nicht nehmen. Klar. Aber seine "Randnotizen" des "geht alles nicht" klingen nach einer Erweiterung mit zu wenig Pins.
Technisch ist das machbar, es wird dann grob vergleichbar zu RS485 sein, ich sehe aber auch keinen offensichtlichen Vorteil ggü RS485. Du musst dann wie bei RS485 üblich das ganze Framing, die Prüfsummen, die ganzen unteren Schichten komplett in Software machen und das einzige was Du sparst sind die CAN-Controller. Aber Tu Dir mal zumindest aus reinem Interesse an Erkenntnis selbst den Gefallen und implementiere eine ganz simple CAN-Kommunikation mit 2 oder 3 echten CAN-Controllern. Dann lehne Dich zurück, sieh Dir an was das Gesamtkonstrukt in dieser einfachen Form bereits zu leisten vermag, was es für Eigenschaften aufweist, und wäge ab wieviel Aufwand (wie erstaunlich wenig eigentlich) das auf Softwareseite unterm Strich war und wieviele Zeilen Code man stattdessen in ein RS485-Protokoll hätte stecken müsste welches exakt das selbe leistet und genauso robust wäre.
:
Bearbeitet durch User
Bernd K. schrieb: > ich sehe aber auch keinen offensichtlichen Vorteil ggü RS485. Mit CAN Transceivern gibts keinen Ärger bei Kollisionen. Also wenn man schon unbedingt selber backen will, dann hat das Vorteile. Für sowas gibts allerdings auch 1-Draht LIN.
m.n. schrieb: > Da Du keine hohe Übertragungsrate brauchst, reicht im einfachsten Fall > ein kleiner 8-pol. µC (ATtinyxx) aus, um am Busverkehr teilzunehmen. Dieser logische Kurzschluss erschließt sich mir nicht. Denn der Aufwand zur Kollisionserkennung und zum gesamten Protokollhandling ist unabhängig von der Datenrate (es gilt hier eben nicht die einfache Beziehung "langsamer=einfacher") und der Controllergröße. Und der wichtigste Knackpunkt: beim CAN gibts zusätzlich zur Adressinformation (welcher andere Teilnehmer bzw. welche Funktion in den anderen Teinehmern wird angesprochen?) nämlich bis zu 8 Bytes an Daten dazu. Allein bis das funktionssicher implementiert ist, hat man die 20 gesparten Euro locker verbraten und nichts brauchbares dabei gelernt. A. K. schrieb: > Mit CAN Transceivern gibts keinen Ärger bei Kollisionen. Also wenn man > schon unbedingt selber backen will, dann hat das Vorteile. Die RS485 Transceiver halten diesen alltäglichen Fehler aber auch bis zum Sankt-Nimmerleinstag aus. Volker S. schrieb: > Ein Controller mit integriertem CAN Das ist bei einer Neuentwicklung sicherlich die sinnvollste Lösung.
:
Bearbeitet durch Moderator
Ein Nicht-Ganz-CAN halte ich auch für nicht sehr sinnvoll. Ich würde sagen: Entweder CAN oder nicht oder z.B. RS-485. Aber das Rad neu erfinden? Eine weitere Möglichkeit wäre eine CAN-Bibliothek (falls es so etwas für den ATMega gibt). Dann brauchst Du nur noch die Treiber so wie in Deinem Bildchen angedeutet. Was hast Du eigentlich gegen den MCP2515. So teuer ist der doch nicht, übermäßig groß ist er auch nicht, aber er erspart Dir aber die ganze CANerei.
Lothar M. schrieb: > Die RS485 Transceiver halten diesen alltäglichen Fehler aber auch bis > zum Sankt-Nimmerleinstag aus. Kollisionen sind mit CAN Transceivern leichter erkennbar. Es gibt keine hässlichen Zwischenzustände. Zudem muss man den Stromverbrauch von Kollisionen nicht in der Stromversorgung berücksichtigen.
Sebastian S. schrieb: > Eine weitere Möglichkeit wäre eine CAN-Bibliothek (falls es so etwas für > den ATMega gibt). Dann brauchst Du nur noch die Treiber so wie in Deinem > Bildchen angedeutet. Also Software-CAN? Auch wenn irgendwie möglich ist das sehr kompliziert und kaum sinnvoll. Der Controller kann dann kaum noch was anderes machen.
@ alle Danke für die konstruktiven Beiträge Der ATMEGA16X ist in dem Heizkörperthermostat verbaut man kann immer - ein Bridge verwenden - - z.B. also Heizkörperthermostat – 2. Controller mit integriertem CAN – CAN Transitiver – CAN BUS - man kann einen Zentralen Master Controller verwenden - - z.B. zu jedem Heizkörperthermostat RS232 in SW genug IOs vorausgesetzt @ A. K. ja, richtig die Kollisionserkennung läuft ja elektisch unterstütz und zerstört nicht das gesendete Datenpaket. 1 Drat LIN ist gut braucht aber einen Master muss man also erst aushandeln wer Master ist und wer übernimmt wen Master ausfällt
A. K. schrieb: > Kollisionen sind mit CAN Transceivern leichter erkennbar. Ist mir bewusst. Trotzdem würde ich dann eben gleich den gesamten "Leistungsumfang" vom CAN nutzen, und eben nicht nur die unterste Ebene, die da für eine automatische, zerstörungsfreie Arbitrierung sorgt. Schon diese simple Sache ist mit der selbstgebastelten UART Lösung nämlich nicht lösbar. Dort gibt es nur zerstörende Kollisionen, die sogar ggfs. erst nach Übertragung des gesamten Datenpakets per Prüfsumme festgestellt werden können.
moin moin, @Heinz-Wilhelm genau so etwas will/muß ich auch realisieren. Und CAN-Bus ist unter allen Varianten der am einfachsten zu nutzende Bus. Beruflich arbeite ich mit USB-HID/CAN/I2C/RS232/RS485. Wie ist die FBH aufgebaut? Trockensystem ( Bauhöhe 20mm ) oder dick mit Estrich ( > 5cm )? VG Pieter
Heinz-Wilhelm F. schrieb: > Der ATMEGA16X ist in dem Heizkörperthermostat verbaut Und es ist ausgeschlossen, mittels Doppelverwendung eines Pins den MCP2515 dran zu hängen? Manchmal kann man Ausgänge mehrfach verwenden, denn in seiner Freizeit (CS=1) ist es dem MCP egal, was SCK/MOSI so treiben, und einer LED ist es egal, wenn es bei Transfers mal leicht flackert. Allein schon damit reichen für den MCP 2 echte Pins, CS und MISO.
Heinz-Wilhelm F. schrieb: > Als Protokoll wird dann aber kein CAN gesprochen, da kein Controller > vorhanden ist, sondern was serielles wahrscheinlich n x 8 Bit mit > Prüfsumme und einem Sync Frame, außerdem wie bei CAN mit Rücklesen über > den RXD zur Kollisionserkennung, > und das ganze ganz langsam Grundsätzlich kannst Du auf der Hardwareschicht natürlich auch eine komplett andere Signalisierung fahren, und ein anderes Datenprotokoll sowieso. Wir haben CAN-Transceiver auch schon als robuste UART-Strecke misbraucht. Aber: die Dinger haben oft eine dominant timeout-Funktion. D.h. wenn TxD zu lange low ist (dominanter Pegel am Bus), dann erkennt der Transceiver einen Fehler und schaltet ab. Du musst also Dein Codierungsverfahren so wählen, dass die längste Low-Phase nicht länger ist als die Filterzeit des verwendteten Transceiver-Bausteins.
Heinz-Wilhelm F. schrieb: > muss man also erst aushandeln wer Master ist und > wer übernimmt wen Master ausfällt Multimaster? Wozu das denn? Soll irgendein Ventil die Master-Funktion übernehmen, wenn ein anderer Master ausfällt? Das Ventil erstellt dann auch die Statistik? Lothar M. schrieb: > Denn der Aufwand > zur Kollisionserkennung und zum gesamten Protokollhandling ist > unabhängig von der Datenrate (es gilt hier eben nicht die einfache > Beziehung "langsamer=einfacher") und der Controllergröße. Kollisionserkennung ist bei einem einzigen Master nicht erforderlich. Ein Leitungschluss ist schnell erkannt. Man kann sich natürlich ein komplexes Protokoll ausdenken, was nur noch von einem GHz-µC zu bewältigen ist. Das ist aber der falsche Ansatz. Langsamer = einfacher paßt bei einer Heizung recht gut: Keine Echtzeit sondern echt viel Zeit. Ich weiß ja nicht, welch überzogene Ansprüche Euch plagen. Ich habe es geschafft, meinen Klingeltaster über 40 m Leitung ganz ohne Protokoll zu abzufragen. Aber gut, wer nur CAN kennt kann es eben nicht anders ;-)
Ich habe selbst mal überlegt den Thermostat umzubauen, es gibt im Netzt schon einige Projekte mit einer alternativen Firmware. A. K. schrieb: > Und es ist ausgeschlossen, mittels Doppelverwendung eines Pins den > MCP2515 dran zu hängen? An der 5Pin-MiniUSB-Buchse sind 5V, GND, MISO, MOSI und CLK herausgeführt. (Die sind auch als Lötpins auf dem PCB) Auf dem PCB sind aber noch 4 weitere Pins zu freien Verfügung, wenn du JTAG nicht brauchst.
m.n. schrieb: > Kollisionserkennung ist bei einem einzigen Master nicht erforderlich. Wir habe für diesen Bus aber offenbar den (gut versteckten) Wunsch nach einer Art Multimasterfähigkeit. Denn Heinz-Wilhelm F. schrieb: >>> Multimaster fähig => Buszugriff muss selbst geregelt werden TOKEN?
C.K. schrieb: > An der 5Pin-MiniUSB-Buchse sind 5V, GND, MISO, MOSI und CLK > herausgeführt. (Die sind auch als Lötpins auf dem PCB) Blöd, dass SPI aber eben mit SS# definiert ist, und viele SPI-Slaves diesen zumindest als Frame-Sync verwenden. Oder andersrum: ein SPI ohne SS# funktioniert nur zufällig. Und nur in störfreier Umgebung. Denn wenn da mal irgendwie ein einziger EMV-Puls auf die SCLK Leitung kommt, dann läuft der ganze Bus um 1 Bit versetzt...
m.n. schrieb: > Im Gegensatz zu den Vorrednern sage ich: Mache es! Sehe ich auch so. soul e. schrieb: > Wir haben CAN-Transceiver auch schon als robuste UART-Strecke > missbraucht. ;-)) Ich auch. Heinz-Wilhelm F. schrieb: > 1 Drat LIN ist gut braucht aber einen Master > muss man also erst aushandeln wer Master ist und > wer übernimmt wen Master ausfällt Den Master legst Du fest und wenn der Master ausfällt, brauchst Du keinen LIN mehr. Es zwingt mich doch Niemand, ein Protokoll zu verwenden, das Eigenschaften mitbringt, die ich hier nicht benötige. Wenn ich also CAN als Level 0 verwende und ein Master - Client Protokoll like LIN aufsetze, wie sollen da Kollisionen entstehen? Die Clients melden sich doch von selbst nicht. Da es hier um eine Fussbodenheizung lt. TO geht, sehe ich keine Notwendigkeit für ein Multimaster-Protokoll. Es geht ja nicht um Drehmomentenkoordinierung und MMS-Eingriffe, sondern um eine sehr träge Regelung. Bei besagter Fussbodenheizung werden sich die Temperaturen vermutlich nicht so rasant ändern, daß eine Arbitrierung mit hoher Priorität für den Temp.-Sensor erforderlich wäre, oder? Der einzige Haken wäre: soul e. schrieb: > Aber: die Dinger haben oft eine dominant timeout-Funktion. D.h. wenn TxD > zu lange low ist (dominanter Pegel am Bus), dann erkennt der Transceiver > einen Fehler und schaltet ab. Da ist es wie immer hilfreich, das Datenblatt schon vor der Beschaffung von BE gelesen zu haben, das schützt vor unliebsamen Überraschungen... Just my 2 Cents Elux
Reiner O. schrieb: > Bei besagter Fussbodenheizung werden sich > die Temperaturen vermutlich nicht so rasant ändern, daß eine > Arbitrierung mit hoher Priorität für den Temp.-Sensor erforderlich wäre, > oder? Das Schöne an CAN ist, dass man sich das ganze Abfragen spart. Die Sensoren senden einfach in fixen Abständen ihre Daten, und CAN sorgt dafür dass alles ankommt. Man kann beliebig neue "Sender" und "Empfänger" hinzufügen, ohne die alten anpassen zu müssen, solange die IDs nicht kollidieren. Auch wenn man Multi-Master nicht zwingend braucht, macht es einiges einfacher.
Dr. Sommer schrieb: > Das Schöne an CAN ist,... Das stimmt Alles. Man kann aber auch bei einer Adressierung Teilnehmer hinzufügen, ohne die Alten anpassen zu müssen. Aber braucht der TO das im beschriebenen Fall auch? Just my 2 Cents Elux
Reiner O. schrieb: > Man kann aber auch bei einer Adressierung Teilnehmer hinzufügen, ohne > die Alten anpassen zu müssen. Dazu muss man aber den Master anpassen. Reiner O. schrieb: > Aber braucht der TO das im beschriebenen Fall auch? Wer weiß ob ihm nicht später noch Erweiterungswünsche kommen. Das ganze ist ja schon eine Erweiterung...
Dr. Sommer schrieb: > Reiner O. schrieb: >> Man kann aber auch bei einer Adressierung Teilnehmer hinzufügen, ohne >> die Alten anpassen zu müssen. > > Dazu muss man aber den Master anpassen. Stimmt; muss man aber (zumindest in diesem Fall) so oder so, denn wenn neue IDs auftauchen müssen die ja auch irgendwo verarbeitet werden. > Reiner O. schrieb: >> Aber braucht der TO das im beschriebenen Fall auch? > > Wer weiß ob ihm nicht später noch Erweiterungswünsche kommen. Das ganze > ist ja schon eine Erweiterung... Das ist richtig; es ließe sich jedoch auch mit dem (vom TO) angedachten Verfahren ohne größere Umstände realisieren. Zur Konkretisierung: Ich habe nichts gegen CAN! Ich frage mich nur, ob der zusätzliche Aufwand eines Controllers/Node im vorliegenden Fall tatsächlich erforderlich/angezeigt ist. Im vorliegenden Fall meine ich, daß Nutzen/Aufwand zu gering ausfällt. Just my 2 Cents Elux
Dr. Sommer schrieb: > Das Schöne an CAN ist, dass man sich das ganze Abfragen spart. Die > Sensoren senden einfach in fixen Abständen ihre Daten Was wäre dann noch der Unterschied zu einem Master, der in fixen Abständen pollt? CAN bzw. Multi-Master lohnt sich doch nur, wenn ich die meiste Zeit Ruhe auf dem Kabel haben will.
Lothar M. schrieb: > C.K. schrieb: >> An der 5Pin-MiniUSB-Buchse sind 5V, GND, MISO, MOSI und CLK >> herausgeführt. (Die sind auch als Lötpins auf dem PCB) > Blöd, dass SPI aber eben mit SS# definiert ist, und viele SPI-Slaves > diesen zumindest als Frame-Sync verwenden. > > Oder andersrum: ein SPI ohne SS# funktioniert nur zufällig. Und nur in > störfreier Umgebung. Denn wenn da mal irgendwie ein einziger EMV-Puls > auf die SCLK Leitung kommt, dann läuft der ganze Bus um 1 Bit > versetzt... Naja... Es ist ja nicht ungewöhnlich, SPI ohne SS# zu fahren. Man nimmt gemeinhin stattdessen timeouts auf SCK, um Datenframes zu unterscheiden. Lässt sich auch alles mit normaler HW (d.h. HW-timer) lösen. Beispielsweise bei den Protokolldekodern von div. Oszis (R&S, Keysight, ...) ist "timeout auf SCK" eine ganz normale Auswahloption, um frames zu unterscheiden und den Bitstrom wieder neu zu synchronisieren. Synchronisierung ohne SS# ist auch nicht wirklich schlechter als mit, denn selbst mit SS# kann es glitches auf SCK geben und alles ist um ein Bit verrutscht. Dann besser SS# ganz weglassen und Prüfsummen nutzen. Habe ich so realisiert in Medizingeräten gefunden, bei denen Daten zwischen einem 32-bit Applikationsmikrocontroller und einem kleineren 8-bit (Hilfs-)Mikrocontroller wechselten.
Reiner O. schrieb: > Stimmt; muss man aber (zumindest in diesem Fall) so oder so, denn wenn > neue IDs auftauchen müssen die ja auch irgendwo verarbeitet werden. Die kann man aber auch auf beliebigen anderen Knoten verarbeiten; komplett neue empfangende Knoten, oder einen beliebigen anzupassenden Knoten. Bei zentralisierten Systemen mit expliziter Abfrage muss man immer noch den Master mit anpassen, ob der die Werte braucht oder nicht... Reiner O. schrieb: > Zur Konkretisierung: Ich habe nichts gegen CAN! Ich frage mich nur, ob > der zusätzliche Aufwand eines Controllers/Node im vorliegenden Fall > tatsächlich erforderlich/angezeigt ist. Ich würde sagen, dass der Entwicklungs-Aufwand bei CAN extrem gering ist. Die ganze Komplexität macht die Hardware. Selbst I²C-Software ist typischerweise komplizierter. Daher würde ich immer "CAN" sagen außer es spricht etwas speziell dagegen (z.B. hohe Datenrate). Bauform B. schrieb: > Was wäre dann noch der Unterschied zu einem Master, der in fixen > Abständen pollt? Man spart sich den Entwicklungsaufwand des Masters. Bauform B. schrieb: > CAN bzw. Multi-Master lohnt sich doch nur, wenn ich die > meiste Zeit Ruhe auf dem Kabel haben will. ... oder das System nicht sehr zentralistisch ist, und auch bei Ausfall des Masters noch bestimmte Dinge tun soll (hier eher irrelevant).
@ Lothar M. und A. K das anbinden eine CAN Controllers via SPI ist keine gute Lösung MISO, MOSI, SCK sind ja rausgeführt aber kein Chip Select und auch kein Interrupt also muss man SPI dann doch in SW ohne HW Unterstützung auf dem ATMEGA machen und zum Temperatursensor muss clever umschalten werden ich weiß jetzt auch nicht wie groß den kompletter CAN Stack für den ATMEGA ist aber ich denke das wird knapp Dann würde ich eine Bridge Lösung vorziehen
@ soul e DANKE! Ein Beitrag wie man sich Ihn wünscht. Wertvoll Informationen.
Lothar M. schrieb: > Und der wichtigste Knackpunkt: beim CAN gibts zusätzlich zur > Adressinformation (welcher andere Teilnehmer bzw. welche Funktion in den > anderen Teinehmern wird angesprochen?) nämlich bis zu 8 Bytes an Daten > dazu. Allein bis das funktionssicher implementiert ist, hat man die 20 > gesparten Euro locker verbraten und nichts brauchbares dabei gelernt. Warum 20 Euro? Bei freundlichen Chinesen gibt es fertige SPI Module mit MCP2515 und TJA1050 receiver für 1.10 Euro. Billiger (und besser) geht es wohl kaum.
Heinz-Wilhelm F. schrieb: > ich weiß jetzt auch nicht wie groß den kompletter CAN Stack für den > ATMEGA ist Wenn du unbedingt CANopen haben willst oder ein Auto drumrum baust... Der MCP2515 pur ist sehr einfach zu nutzen. Einen komplizierten Stack braucht man nicht, wenn es reicht, Messages mit 8 Bytes zu versenden. Ich hatte den mal an einen Mega8 gehängt, mit 3 trivialen Layern: SPI, MCP, Anwendung. > aber ich denke das wird knapp Nö. > und auch kein Interrupt Eine Interrupt-Leitung ist unnötig, wenn es nicht eilig ist und Polling ausreicht. > also muss man SPI dann doch in SW ohne HW Unterstützung auf dem ATMEGA > machen SPI als Master zu Fuss zu implementieren ist extrem einfach.
:
Bearbeitet durch User
Heinz-Wilhelm F. schrieb: > @ Lothar M. und A. K > > das anbinden eine CAN Controllers via SPI ist keine gute Lösung > MISO, MOSI, SCK sind ja rausgeführt aber kein Chip Select und auch kein > Interrupt > also muss man SPI dann doch in SW ohne HW Unterstützung auf dem ATMEGA > machen und > zum Temperatursensor muss clever umschalten werden Dann nimm anstelle eines MCP2515 einen PIC18F26K80. Der kostet nur wenig mehr, enthält eine deutlich verbesserte Version des CAN-Controllers aus dem MCP2515 und hat zusätzlich noch Prozessor, Flash, RAM, UART, SPI/I2C etc mit drin. Gibts in QFN, wenn es klein sein muss, aber auch in SOIC und in SPDIP für Lochraster. Die Kommunikation zwischen ATMEGA und PIC machst Du entweder über Software-I2C, oder Du leitest den Hardware-UART des ATMEGA nach außen - die beiden Pins sollten nämlich frei und unbenutzt sein, so wie ich das sehe. Dann macht der PIC die ganze Kommunikation intern, und zwischen ATMEGA und PIC werden nur einfache, kurze Datentelegramme ausgetauscht. fchk
Frank K. schrieb: > Dann nimm anstelle eines MCP2515 einen PIC18F26K80 Der 80er kostet immer noch ~1€ mehr als der 83er und ein 25k ist billiger als ein 26k und tut es da locker!
Ich habe mal auf einem PIC einen Minimaltreiber für den MCP2515 gebaut, das war erstaunlich wenig Code. Anfangs habe ich auch beim ersten Blick in das Datenblatt gedacht, dass das viel Arbeit wird - das ging dann erstaunlich schnell und schlank. Bzgl. des fehlenden CS: Es gibt eine Möglichkeit, mit nur 3 Pins an einem MCP2515 auszukommen: CLK, SDO und SDI werden direkt angeschlossen. CS wird über einen RC-Tiefpass von SCLK abgeleitet. Man hält die High-Pulse des SCLK sehr kurz und somit bleibt CS hinter dem Tiefpass auf 0. Am Anfang eines Frames hält man SCLK etwas länger auf 0 und zum Schluss lässt man SCLK auf 1. Ich muss zugeben, dass ich das konkret für den MCP2515 noch nicht getestet habe, wohl aber für einen anderen SPI-Baustein. Sollte aber laut Diagrammen im Datasheet funktionieren. Als Phy käme der SN65HVD234 in Frage. Das Enable dieses Transceivers hängt man an einen Buffer-Full Output des MCP2515, dann kann der in Sleep-Modi mit 1..2uA gehen. Diese Pins können als GPIO genutzt werden. Bliebe die Versorgungsspannung: MCP2515 ist runter bis 2,7V spezifiziert, etwas weniger geht bestimmt auch. Der SN65HVD234 ist mit min. 3,0V „recommended“, sollte aber auch mit weniger funktionieren. Wie wärs damit? Ein Heizungsregler mit echtem CAN ohne innere Modifikation erscheint möglich.
Bzgl. der Versorgung aus der Batterie für den SN65HVD234: Ein Boost im SOT23 mit Enable, der ebenfalls per GPIO gesteuert wird, wäre z.B. ein TPS613221A für 3.3V oder ein TPS613225A für 3.0V.
OK, ich mach noch mal ein paar Erläuterungen. Im Thermostate ist ein ATMEGA16X verbaut. Das ISP ist von Außen in Form einer physikalisch Mini USB Schnittstelle zugänglich. Mann kauft also ein Thermostate und hängt es an den ISP Programmieradapter und flasht die Customer Firmware, dann wird es montiert. Stromversorgung erfolgt normalerweise über 2AA Batterie, hier wird über die „USB“ Schnittstelle die Versorgungsspannung, wahrscheinlich 3,3V. bereit gestellt. Deshalb wird ein USB Kable in Buchse des Thermostate gesteckt. Fertig! Dann hab ich 3 IO PINs (MISO, MOSI, SCK) frei. Wenn ich den Temperatur Sensor weglasse. Wie schließe ich dann den MCP2515 an? Mache ich SPI in SW oder in HW? Wie hole ich das ATMEGA16X aus dem Tiefschlaf? Worauf den Interrupt? Die CAN Bootloader libary lauft anscheinend mit HW SPI? Beitrag "CAN Bootloader für AVRs und MCP2515" Ist sicher Unerfahrenheit aber irgendwie sehe ich nicht wie das Funktioniert.
Mit Batteriebetrieb sind Feldbusse auf Basis von RS-485 oder CAN Transceivern schlecht zu vereinbaren. Wenn man allerdings schon Strippen zieht, kann man den Strom auch mitbringen.
Angehängte Dateien:
-
HeitzKeisVerteiler.JPG
100 KB
und noch ein Foto, weil nicht jeder was mit Heizkreisverteiler und Fußbodenheizung was anfangen kann.
@ Harald Danke für den Beitrag, wir müssen wohl parallel am schreiben gewesen sein, denn ein Paar meiner Fragen hast Du ja schon beantwortet. Anschluss Schema – verstanden SPI ist dann in SW wegen der unterschiedlichen Pulslängen auf den SCLK Bootloader müsste dann im SPI Teil angepasst werden
Flashen lässt sich der Thermostat über die Buchse nicht, da die Resetleitung fehlt. Du musst es also aufschrauben. Ich würde die Buchse rauslöten. Der 4. Pin (ID-Pin) ist hier mit MISO belegt und in den Steckern nicht belegt ist. Da kommst du mit einem Standard-USB-Kabel also nicht ran. Führe durch die Öffnung dann ein Kabel durch und löte sie auf die freien Pin Pads. Auf der Platine sind da zwei mal 2x3 Lötpunkte. einmal für ISP (Vcc, GND, Reset, MISO/PB3, MOSI/PB2, SCK/PB1) und einmal JTAG (Vcc, GND, TDI/PF7, TDO/PF6, TMS/PF5, TCK/PF4) Deaktiviere beim Flashen JTAG und du hast die 4 JTAG-Pins frei, die obendrein auch ADC-Pins sind.
A. K. schrieb: > Mit Batteriebetrieb sind Feldbusse auf Basis von RS-485 oder CAN > Transceivern schlecht zu vereinbaren. Wenn man allerdings schon Strippen > zieht, kann man den Strom auch mitbringen. Da gebe ich Dir grundsätzlich Recht, als Industriedesign würde ich das auch nicht anbieten wollen. Hier hat man jedoch recht kontrollierte Bedingungen und der SN65HVD ist im Gegensatz zu den üblichen Verdächtigen recht sparsam. Klar, der Bus ist halt so stromhungrig wie er ist, aber das könnte passen.
Bzgl. INT-Leitung am MCP2515. Ich will den Sinn garnicht wegdiskutieren, wenn aber nur wenige Daten im Spiel sind würde ich das rein per Polling machen. Es gibt ein Kommando, wo man mit nur einem Byte SPI Austausch den Nachrichteneingang prüfen kann. Bei richtig konfigurierten Filter bekommt man auch nur wenige Nachrichten. Außerdem kann das Konzept bei Sleep am Slave auch nur wie folgt aussehen: Slave wacht auf und aktiviert den CAN. Slave versendet eine Nachricht an den Master, der immer wach ist. Slave wartet eine gewisse Zeit auf einen Nachrichtenversand durch den Master (z.B. 2sec) und legt sich wieder komplett schlafen.
@ C.K. Du hast fast Recht. Der Reset Pin ist über die Platien erreichbar. mit einem modifizierten Adapter. http://www.mikrocontroller.net/attachment/60461/PrgSteck2.jpg Es gibt voll belegte Mini USB Stecker - hab ich schon, die Beschaffung ist unproblematisch. Kabel ran löten sollte auch kein Problem sein.
Man könnte auch einen LPC11C00 Mikrocontroller dazu packen. Dieser hat den CAN Controller und Transceiver mit dabei. Der könnte die gesamte CAN Kommunikation abwickeln und die Daten per SPI/UART/whatever an den ATmega schicken. So braucht es nur 1 zusätzliches IC...
Dr. Sommer schrieb: > Man könnte auch einen LPC11C00 Mikrocontroller dazu packen. Dieser > hat > den CAN Controller und Transceiver mit dabei. Der könnte die gesamte > CAN Kommunikation abwickeln und die Daten per SPI/UART/whatever an den > ATmega schicken. So braucht es nur 1 zusätzliches IC... Gute Idee, allerdings benötigt der für die Phy genau 5V. Und kein Sleep-Modi. Würde also externe Versorgung voraussetzen.
Harald schrieb: > Und kein Sleep-Modi Sollte nicht jeder ARM mindestens den "Idle" Modus haben ("WFI")?
Heinz-Wilhelm F. schrieb: > das anbinden eine CAN Controllers via SPI ist keine gute Lösung Wie sagte mein Bekannter, der für mich das Auto repariert, als ich ihn fragte: "Das Ding wird mit seinen 13 Jahren auch schon langsam alt und es klemmt hier und es klappert da und er fängt auch schon an zu rosten und die Scheibe hat ein kleines Loch, und, und... willst du den schon noch reparieren?" Er sagte: "Wenn du unbedingt einen Neuen kaufen willst, dann sag das doch einfach!" Und so ist das hier auch: wenn du unbedingt deinen eigenen Bus machen willst, dann tu das. Die CAN-Treiber sind prinzipiell dafür geeignet. Friedrich schrieb: > Naja... Es ist ja nicht ungewöhnlich, SPI ohne SS# zu fahren. Man nimmt > gemeinhin stattdessen timeouts auf SCK, um Datenframes zu unterscheiden. > Lässt sich auch alles mit normaler HW (d.h. HW-timer) lösen. Ja, habe ich auch schon gemacht. Ist trotzdem vogelwildes Gebastel, das sich drauf verlässt, dass kein Unbedarfter die Software ändert und diese Pausen ändert. Denn dann startet z.B. ein Spike auf der Clockleitung eine Übertragung, die dann wieder irgendwie per Totzeit totgeschlagen wird. So ist SPI grundlegend nicht definiert. > Beispielsweise bei den Protokolldekodern von div. Oszis (R&S, Keysight, > ...) ist "timeout auf SCK" eine ganz normale Auswahloption, um frames zu > unterscheiden und den Bitstrom wieder neu zu synchronisieren. Bei einem Oszi ist das durchaus eine gute Triggermöglichkeit, wenn man z.B. keinen Kanal für den SS# mehr frei hat. Aber es ist auch dort nur eine Notlösung.
Harald schrieb: > Und kein Sleep-Modi Aus dem DB: Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes. Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
@ Harald Danke, sehr konstitutive Beiträge. Du bist der einzige der nicht nur sagt, nimm einen MCP2515. Sondern der auch zeigt, was es möglich wäre. Aber, Funktionstrennung mit einem zusätzlichen Bridge Mikrokontroller mit integriertem CAN Controller ist vom Konzept her wohl besser. Es wird in beiden Fällen zusätzliche Hardware ungefähr gleichen Preises verwendet. Die Modularisierung steigt die gesamt Komplexität sinkt. Und man hätte dann die Möglichkeit, mehr Funktionalität abzudecken. Thermostat – seriell – Bridge MC – CAN Transceiver …. - serieller Bootloader könnte genutzt werden - Tiefschlaf zum Stromsparen bei allen Komponenten - viel Hardware Support im Bridge MC
@ alle ################################################## Die Variante mit externem CAN Controller angebunden via SPI ist raus. ##################################################
Bei den zu erwartenden Kabellängen und Datenraten würde ich auf LIN-Bus setzen, selbst mickrige 1200Baud würden in deinem Fall doch völlig reichen. Irgendwo hatte ich mal ein bus-powered-Beispiel gesehen, hat natürlich Grenzen mit der Anzahl der Teilnehmer. Das wäre dann eine Zweidrahtleitung, ohne nennenswerten Batterieverbrauch. Wieviele Thermostate sind es denn? Ja, läuft dann auf master/slave hinaus, aber da sehe ich in deinem Fall keinen Nachteil.
@ Lothar M. Du sprichst hier immer von Autos, darum ich jetzt auch mal. Ja, ich finde die Räder und die Radmuttern toll(CAN BUS). Und der Beitrag existiert um herauszufinden, wie denn das Auto drum herum aussehen sollte. Allerdings gibt es von Auto schon das Chassis und den Motor (elektronische Thermostat). Du schlägst von, nimm doch gleich das Getriebe und den Antriebsstrang (externen CAN Cotroller, MCP2515). Wie Du jetzt selbst festgestellt hat, passt vorhandene Motor und vorgeschlagen Getriebe mit Antriebsstrang nicht zusammen. Auch habe ich den Eindruck das, wenn man den Antriebsstrang (CAN Protokoll) nutzen möchte, dann braucht man einen spezielles Getriebe (CAN Controller) oder gleich Getriebe mit Hilfsmotor (Bridge MC). Da ich, vermutlich wegen Unerfahrenheit, die gesamt Komplexität nicht sehe, brauche ich Unterstützung, das richtigen Getriebe mit Antriebsstrang zu finden.
Heinz-Wilhelm F. schrieb: > Die Modularisierung steigt die gesamt Komplexität sinkt. > Und man hätte dann die Möglichkeit, mehr Funktionalität abzudecken. wow! Ich verleihe den goldenen Dilbert für Projektmanagement. Zusammenfassung der bisherigen Beiträge: TO: Ich will ein CAN ähnliches Protokoll selbst bauen. MC: nö ist eine Dumme Idee und von der Funktionalität ein Overkill. RS485 vll? TO: ICH WILL CAN!!! aber keine sorge, es gibt Abhilfe: CAN als reine Softwareimplementierung: http://caraca.sourceforge.net/ have fun
Was soll I2C ? Einen Pin oder zwei gegenueber SPI sparen ? I2C ist sowas von vermurkst wenn man mehr Funktionalitaet wie einen Temperatursensor auslesen will.
Dr. Sommer schrieb: > Harald schrieb: >> Und kein Sleep-Modi > > Aus dem DB: > > Integrated PMU (Power Management Unit) to minimize power > consumption during Sleep, Deep-sleep, and Deep power-down modes. > Three reduced power modes: Sleep, Deep-sleep, and Deep power-down. Ja, richtig. Leider ist beim LPC11C24 (den meinst du vermutlich) der Transceiver als eigenes Die auf dem Chip. Daher ist auch die Versorgung 5V CAN explizit rausgeführt. Der Transceiver-Chip hat leider keinen Sleep-Modi. Wenn man so etwas bauen möchte, müsste man die 5V CAN schaltbar machen und im Sleep-Modi des Controllers diesen abschalten. Ansonsten nuckelt der etliche mA aus der Versorgung. Dann lieber den LPC11C14 ohne Transceiver und einen SN65HVD234 andocken. Dann lässt sich beides mit 3.3V versorgen und man hat einen schönen Sleep-Pin für den Transceiver.
Harald schrieb: > Daher ist auch die Versorgung > 5V CAN explizit rausgeführt. Der Transceiver-Chip hat leider keinen > Sleep-Modi. Achso, ja das ist blöd. Btw, "Modi" ist Plural, also "keinen Modus" oder "keine Modi"...
@ dogbert Danke für die Blumen, so ganz kann ich deinem Beitrag nicht folgen aber Du dem Thread ja anscheinend auch nicht. Also noch mal Ich brauche eine BUS. Ich habe 3 PINs frei. Physikalisch Soll der Bus mehrere Teilnehmer unterstützen. Dafür benötigt man Treiber, die Kauft man. Bleibt RS485 und CAN. Dann nimmt man CAN weil elektrisch einfacher zu detektierende Kollisionserkennung. Bis zu der Stelle ist noch kein Rede von irgend irgend einem Protokolle, dass auf dem BUS gefahren werden soll. OK, ich manage den Thread schlecht, ich sage den Leuten nicht Halts Maul der Scheiße ist nicht Zielführend. Die Frage ist, ob eine vollständige Implementierung von CAN, also die Verwendung des Protokolles sinnvoll ist für die Aufgabe, nur weil zufällig der Physikalisch Bus CAN ist. Zu der von Dir vorgeschlagenen Softwareimplementierung. Da muss aber noch ganz schön viel angepasst werden bis das läuft. Ne Tonne inline assambler auf nem andern Controller Typ. Danke.
Wie komplex ist denn die bestehende Software für den ATmega, dass man den unbedingt behalten muss?
Heinz-Wilhelm F. schrieb: > Dann nimmt man CAN weil elektrisch einfacher zu detektierende > Kollisionserkennung. Wenn man überhaupt eine Kollisionserkennung braucht. Wenn du nur 1 Master im Bus hast, der die x Slaves zyklisch pollt, dann brauchst du keine Arbitrierung und keine Kollisionserkennung. Der Ablauf ist klar: der Master fordert an und 1 einziger der Slaves antwortet. Keiner der Slaves quatscht von sich aus los. Niemals! Fertig ist der Bus und man kann RS485 verwenden, der dank der beiden dominanten Pegel physikalisch störsicherer als CAN ist und mit einer simplen seriellen Schnitte angesteuert werden kann.
@ alle Irgendwie denke ich das LIN nicht passt! Lasse mich gern eines besseren belehren. Anzahl der Teilnehmer ist größer als 16. Die Thermostat sind Verschleißteile und müssen gewechselt werden können. Das heißt keine allgemein Firmware falschen sondern die, mit passender Adresse. In eine Raum sind mehrere Heizkreise, also mehre Thermostate, die zusammen Arbeiten müssen,schlechtes Design, wenn dies so gar keine Berücksichtigung findet. Master ist gleich singel point of allet failt. Wenn es vom Konzept her einen pollenden Master Controller geben sollte, dann gibt es keinen Grund mehr LIN zu verwenden. Dann wird der Master Controller so groß, das jedes Thermostat direkt angeschossen werden kann. Und wenn man das was bei LIN nicht passt weglässt oder ändert, dann bleibt bis auf den PHY nix mehr übrig.
Heinz-Wilhelm F. schrieb: > Dafür benötigt man Treiber, die Kauft man. > Bleibt RS485 und CAN. Du kannst auch Single-Master Halbduplex mit Single-wire-wired-or (Open-Collector mit Pullup) machen, das ginge unter Umständen sogar mit nur einem einzigen Pin direkt aus dem µC heraus und ohne Treiber, je nachdem wie sich der UART und die GPIO-Modi konfigurieren lassen, notfalls sogar mit Soft-UART auf nem AVR. Baudrate darf ja anscheinend ziemlich niedrig sein. Man könnte sogar auf das wired-or verzichten und den Pin in beide Richtungen aktiv treiben wenn man nur einen Master hat und daher sichergestellt ist daß Kollisionen gar nicht erst auftreten können.
:
Bearbeitet durch User
Heinz-Wilhelm F. schrieb: > Dann wird der Master Controller so groß, > das jedes Thermostat direkt angeschossen werden kann. Die Logik musst du jetzt aber mal erklären... Was genau macht überhaupt der Master? Steuert der irgendeine Hardware? Oder würde der nur Daten durchleiten? In diesem Fall ist CAN überlegen - da braucht es überhaupt keinen Master, alle Slaves senden regelmäßig ihre Daten (die Hardware verhindert Kollisionen) und jeder Slave empfängt das, was ihn interessiert.
Heinz-Wilhelm F. schrieb: > Wenn es vom Konzept her einen pollenden Master Controller geben sollte, > dann gibt es keinen Grund mehr LIN zu verwenden. > Dann wird der Master Controller so groß, > das jedes Thermostat direkt angeschossen werden kann. Ab hier wird es wohl überflüssig, noch weiterzulesen.
Dr. Sommer schrieb: > Btw, "Modi" ist Plural, also "keinen Modus" oder > "keine Modi"... Danke für den Hinweis, aber ich darf das! ;-)
Harald schrieb: > Danke für den Hinweis, aber ich darf das! ;-) Hehe... Warte bis du die korrekte Deklination und Pluralbildung von "Status" siehst :P https://www.duden.de/rechtschreibung/Status
OK, ich mach noch mal ein paar Erläuterungen. Das Thermostat ist der Aktor mit integrierter Regelung. Der braucht die Rücklauftemperatur – Temperaturgefälle entspricht Energieabgabe - interessiert eigentlich nur das jeweilige Thermostat selbst die Vorlauftemperatur – um die Differenz zum Rücklauf bilden zu können - dies ist für alle Thermostat gleich, muss also Zentral zugreifbar sein die Aktuell Raumtemperatur – ist Wert, für den jeweiligen Raum die Gewünschte Raumtemperatur – soll Wert, für den jeweiligen Raum In Einem Raum sind mehrere Heizkreise die Physikalisch unterschiedlich sind und individuell nach gleich Vorgaben geregelt werden müssen. Die Raumtemperaturvorgabe erfolgt durch von Außen, irgendwo sitzt ein große Master Controller der als Gateway die Nutzervorgaben entgegennimmt. Bei der Aktuellen Raumtemperatur wird es schon schwieriger. - zum Teil mechanisch verstellbare Thermostate die bei der eingestellten Temperatur öffnen oder schließen. - fest montierte eklektisch Temperatursensoren, mit MC der die Daten aufbereitet - kabellose Temperatursensoren deren Werte via Gateway weitergeleitet und aufbereitete werden Es gibt also immer einen Master Controller mit Gateway Funktion, der die Schnittstelle nach außen bildet. Wahrscheinlich Ethernet mit Webserver zur Konfiguration und SDkarte zu speichern von Statistikdaten zur Optimierung des Regelverhaltens. Als Master Controller würde ich eher auf eine Linux Kiste setzen, ala Rasbery Pi, OpenWRT, irgendwas was sowieso schon läuft. Die Idee ist dann ja, dass bei einem kurzeitgen Ausfall das eigentliche System nicht betroffen ist. Man kann das aber auch gut mit einem Cortex M4 hinkriegen. Es gibt diverse Boards die alles mitliefern. Der hat genug IO um die Thermostate direkt anbinden zu können. Dann hab ich nen so richtigen Maste Controller der immer laufen MUSS.
moin moin, @Heinz-Wilhelm genau so etwas will/muß ich auch realisieren. (gestrichen) Wie ist die FBH aufgebaut? Trockensystem ( Bauhöhe 20mm ) oder dick mit Estrich ( > 5cm )? VG Pieter
@ Pieter bitte entschuldige das ich deine erste Nachfrage ignoriert habe. Bei mir ist es Beton Estrich also >5cm, sollte aber keinen Unterschied machen. Denn nur das Regelverhalten ist dann anders.
Heinz-Wilhelm F. schrieb: > Irgendwie denke ich das LIN nicht passt! Lasse mich gern eines besseren > belehren. LIN wird erst zum LIN, wenn Du das passende Protokoll fährst. Also den SW-Stack mit Master- und Slave-Implementierung. Ansonsten ist das UART mit +12V/0V statt +5V/0V. Du kannst auch UART mit -9V/+9V machen, das nennt man dann RS-232. Oder halt UART mit deltaU = 1,5V/3,5V mit CAN-Transceivern, das wäre der Vorschlag vom Anfang. Der hätte den Vorteil der differentiellen Datenübertragung und den Nachteil dass man ein Kabel mehr braucht. (Auch differentielle Signale brauchen Masse, ausser man hat ideale Bauteile mit unendlich großem common mode-Bereich).
Angehängte Dateien:
-
Verteiler.jpg
67 KB
Hallo Heinz-Wilhelm, meine 2cm brauchen gefühlte 1 Stunde bis sich am Boden was ändert. Da was "regeln" dauert. Meine Überlegung geht dahin, direkt an die Motörchen der Thermostate Drähte anlöten und die zentral an eine Platine mit MC. Dazu Temperatursensoren aus den Räumen und Aussentemperatur an den MC und der speicher auf SD. VG Pieter
soul e. schrieb: > ausser man hat ideale Bauteile > mit unendlich großem common mode-Bereich). Oder floatende Geräte.
@ Pieter dein Vorhaben ist nicht zielführend. Dafür gibt es extra nur Stellmotore, ohne das Du das Thermostat umbauen musst. ist nur ein Beispiel, was ich auf die schnelle gefunden habe, ab 80€ bekommt man sowas. https://www.voelkner.de/products/1176920/Siemens-BPZSSA955-1St..html Die elektrischen Thermostate ala THERMY haben eine Endlagenerkennung über Strommessung, die geht verloren, wenn Du den Motor direkt ansteuerst und alles funktioniert nicht mehr.
Ich habe gerade nochmal etwas geschaut, wie man aktuell einen möglichst kleinen und einfachen eigenintelligenten CAN Knoten aufbauen könnte - interessierte mich auch gerade selber für ein aktuelles Projekt. Meine Wahl dazu wäre ein STM32F042F6 als Controller und ein MAX3051 Transceiver im SOT23-8(!), dazu ein 12Mhz Quarz im 2025 Gehäuse. Alle drei Komponenten gibt es bei lcsc.com zum Gesamtpreis von <2€ (bei Menge 30Stück). Das alles zusammen passt auf wenige Quadratmillimeter Platinenfläche. Alles lässt sich schön in Idle versetzen und braucht kein Kraftwerk für den Betrieb. Dazu alles Single 3.3V, keine sonst übliche 3.3/5V Kombi.
moin moin, @Heinz-Wilhelm, EIN Thermostat kostet mich im BM ganze 8,00€. Die Strommessung ist kein Problem. Ganz im Gegenteil, wenn darüber die Endlagenerkennung funktioniert wird die Sache sogar einfacher. VG Pieter
Ich finde auch, daß CAN besonders einfach zu programmieren ist. Jeder sendet und empfängt, wie er lustig ist und die CAN-Hardware sorgt automatisch dafür, daß alles richtig ankommt. AVRs mit CAN sind z.B. AT90CAN128, ATmega64M1 und deren kleineren Brüder.
Peter D. schrieb: > AVRs mit CAN sind... leider schweineteuer :-( (((macht bei 10 St. natürlich nichts, wenn man dafür aufgrund von Erfahrung und vorhandener Entwicklungsumgebung wieder einiges an Zeit einspart)))
:
Bearbeitet durch User
Volker S. schrieb: > leider schweineteuer :-( Ja, da hatte sich Atmel wahrlich nicht mit Ruhm bekleckert, bei den Xmega haben sie CAN sogar völlig vergessen. Bei den PIC sieht das wohl günstiger aus. Allerdings sollte es dann schon ein PIC18 oder höher sein, wegen Softwarestack, Interruptvektoren, linearer RAM/Flash-Adressierung und C-Programmierung.
Peter D. schrieb: > Allerdings sollte es dann > schon ein PIC18 oder höher sein, wegen Softwarestack, Interruptvektoren, > linearer RAM/Flash-Adressierung und C-Programmierung Yep, auch da keine alten Gurken. Die sind auch immer (extrem?) viel teurer als aktuelle und bieten dafür weniger ;-) Kleiner als PIC18 gibt es wohl gar nicht. Von denen ein K83 zum Preis eines MCP2515 ist OK. Die K83 sind aus der relativ neuen Generation mit IR-Vektortabellen, was ja traditionell bei den PIC18 nicht der Fall war. Die hatten immer nur 2 Vektoren für hohe und niedrige Priorität...
:
Bearbeitet durch User
@ Peter, Volker und Harald Für die Bridge Lösung würde ich einen STM32F103C8T6 aka blue pill nehmen und ein CAN Transceiver auf PCB, made by China. Eine PCB auf der alle zusätzliche Komponente sitzen, kann man bei verstärktem Interesse ja später immer noch fertigen. Die „USB“ Buchse zum Thermostat, der Britge IC mit integriertem CAN Controller und der CAN Transceiver, sowie Anschlussklemmen für den OneWire Temperatursensor, und den CAN BUS. Den STM32F103 kann man dank ARM Cortex M0 später bei Bedarf durch was anderes ersetzten.
Heinz-Wilhelm F. schrieb: > Für die Bridge Lösung würde ich > einen STM32F103C8T6 aka blue pill nehmen > und ein CAN Transceiver auf PCB, made by China. Oder ein Olimexino-STM32 - vielleicht etwas teurer, aber praktischer. https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/open-source-hardware Heinz-Wilhelm F. schrieb: > Den STM32F103 kann man dank ARM Cortex M0 > später bei Bedarf durch was anderes ersetzten. Das ist ein Cotex-M3.
Heinz-Wilhelm F. schrieb: > Für die Bridge Lösung würde ich > einen STM32F103C8T6 aka blue pill nehmen > und ein CAN Transceiver auf PCB, made by China. Die Boards sind ja oft billiger als der nackte Controller und wenn du erst mal kein Board machen willst... (persönlich mag ich das Gebastel mit lauter Einzelplatinen nicht so, da fräse ich mir lieber schnell was ;-)
Angehängte Dateien:
-
SN65HVD230.png
20 KB -
SN65HVD230.jpg
56 KB
CAN Bus Transceiver mit 3.3 V Single Supply Operation scheint es nur von MAXIN MAXLiniar und TI zu geben alle haben sinniger weise + Standby mit Lauschmodus + ESD Protection + Thermal Shutdown Protection + Ohne VDD Output high impedanz + gleiches PIN Layout SN65HVD230 + weit verbreitet und preiswert ++Ebay Stück ca. 40 Cent mit Versand bei min 5 Stück - kein Sleep Moode (wird für den Fall auch nicht benötigt) Es gibt noch modernere mit mehr Funktionen oder Robuster. Aber so richtig was verkehrt machen kann man anscheinend nicht. Im Datenblatt ist auch ein Layout Fortschaltung. Siehe Bilder. Ist viel Vorsicht in Schaltungsvorschlag. Filtern an den Eingängen ... Nur D1 hab ich irgendwie nicht gerafft. Hat aber eh was mit der Symmetrischen Bus Terminierung und der Funktion von Vref zu tun. Was die Chinesen da als fertige PCB liefern ist eher schmal. Sieht so aus, als ob der BUS Therminirungswiederstand mit drauf ist und der pull up an Rs für die Busgeschwindigkeit. Dann kann man das Teil gleich auf ne SOP Adapter Platine nagel, für diese Beschaltung braucht man dann auch keine „fertige“ PCB.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.