Forum: Mikrocontroller und Digitale Elektronik Physikalischer CAN Bus mit Transceivern aber ohne CAN Controller


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Heinz-Wilhelm F. (h-w-frickelfixer)


Angehängte Dateien:

Lesenswert?

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?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Harald (Gast)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Volker S. (vloki)


Lesenswert?

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
von m.n. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Sebastian S. (amateur)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ 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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Pieter (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Soul E. (souleye) Benutzerseite


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 ;-)

von C.K. (Gast)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Reiner O. (elux)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

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.

von Reiner O. (elux)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

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

von Reiner O. (elux)


Lesenswert?

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

von Bauform B. (bauformb)


Lesenswert?

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.

von Friedrich (Gast)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ 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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ soul e

DANKE!

Ein Beitrag wie man sich Ihn wünscht.
Wertvoll Informationen.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Frank K. (fchk)


Lesenswert?

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

von Volker S. (vloki)


Lesenswert?

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!

von Harald (Gast)


Lesenswert?

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.

von Harald (Gast)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Angehängte Dateien:

Lesenswert?

und noch ein Foto,
weil nicht jeder was mit Heizkreisverteiler und Fußbodenheizung was 
anfangen kann.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ 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

von C.K. (Gast)


Lesenswert?

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.

von Harald (Gast)


Lesenswert?

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.

von Harald (Gast)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

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

von Harald (Gast)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

Harald schrieb:
> Und kein Sleep-Modi

Sollte nicht jeder ARM mindestens den "Idle" Modus haben ("WFI")?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ 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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

@ alle

##################################################
Die Variante mit externem CAN Controller angebunden via SPI ist raus.
##################################################

von H.Joachim S. (crazyhorse)


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von dogbert (Gast)


Lesenswert?

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

von Pandur S. (jetztnicht)


Lesenswert?

Was soll I2C ? Einen Pin oder zwei gegenueber SPI sparen ?
I2C ist sowas von vermurkst wenn man mehr Funktionalitaet wie einen 
Temperatursensor auslesen will.

von Harald (Gast)


Lesenswert?

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.

von Harald (Gast)


Lesenswert?

Harald schrieb:
> als eigenes Die auf dem Chip

als eigenes Die im Gehäuse sollte es heißen.

von Dr. Sommer (Gast)


Lesenswert?

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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

Wie komplex ist denn die bestehende Software für den ATmega, dass man 
den unbedingt behalten muss?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

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
von Dr. Sommer (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Harald (Gast)


Lesenswert?

Dr. Sommer schrieb:
> Btw, "Modi" ist Plural, also "keinen Modus" oder
> "keine Modi"...

Danke für den Hinweis, aber ich darf das! ;-)

von Dr. Sommer (Gast)


Lesenswert?

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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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.

von Pieter, zum 2.mal (Gast)


Lesenswert?

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

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Soul E. (souleye) Benutzerseite


Lesenswert?

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

von Pieter (Gast)


Angehängte Dateien:

Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

soul e. schrieb:
> ausser man hat ideale Bauteile
> mit unendlich großem common mode-Bereich).

Oder floatende Geräte.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Harald (Gast)


Lesenswert?

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.

von Pieter (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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
von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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 ;-)

von Heinz-Wilhelm F. (h-w-frickelfixer)


Angehängte Dateien:

Lesenswert?

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.

von Heinz-Wilhelm F. (h-w-frickelfixer)


Lesenswert?

Volker S. schrieb:

> da fräse ich mir lieber schnell was ;-)

mein Neid sei Dir gewiss.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.