Forum: Mikrocontroller und Digitale Elektronik Robuste Datenkommunikation für beliebige Kabel und Topologien nach Vorbild CAN


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 Andre B. (andrebx)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe für die Erweiterung meiner Hausautomatisierung einen 
Kommunikationsbus entwickelt, der mit nur einer Datenleitung, beliebigen 
auch ungeschirmten Leitungen und Topologien funktioniert.

Als Vorbild diente mir der CAN-Bus, von dem ich die für mich wichtigsten 
Ideen und Features übernommen habe:
- Prioritätssteuerung der Nachrichten nach ID
- Multi-Master-System: alle können gleichzeitig senden
- Fehlerkontrolle per Parity Bits

Die Datenleitung wird über einen Pullup gegen Hi gezogen. Dies ist der 
rezessive Zustand. Jeder Busteilnehmer verfügt über einen Transitor, der 
den Bus gegen Low ziehen kann (dominant). Die Information selbst wird 
anders als bei CAN über die Länge des Pulses dargestellt. Eine logische 
"1" ist ein kurzer Puls, eine logische "0" ein langer. Die maximale 
Datenrate ergibt sich durch die Länge der Pulse (default 4ms und 8ms) 
und die Pausenzeit dazwischen (default 2ms). Siehe angehängte PDF-Datei.

Es wird für einen Arduino insgesamt also eine 3-adrige Leitung benötigt 
(5V, Gnd, Signal). Im System ist nur ein Pullup vonnöten, mehr gehen 
natürlich auch. Optional kann man LEDs mit dranhängen, notwendig ist pro 
Teilnehmer allerdings nur ein einziger Transistor (für Open-Collector).

Die Nachrichten haben eine Länge von 30 Bit und folgendes Format:

Message Structure
  ID Value Parity
  10   16     4 Bits = 30 Bits
 3FF  FFFF    Maximalwert

Damit können nur etwas 5 Nachrichten pro Sekunde verschickt werden. Das 
reicht mir für meine Anwendung vollkommen aus, da ich Signale wie 
Wasserstände und Bodenfeuchtigkeiten übertrage. Bei Bedarf können die 
Zeiten natürlich verkürzt werden.

In meinem System habe ich in Sterntopolgie 3 Strom-Erdkabel 
zweckentfremdet (je ca. 20m) und mehrere Telefonleitungen. Mit dem 10k 
Pullup könnte ich noch etwa 2-3 mal schneller. Wer's noch schneller 
braucht kann den Pullup reduzieren und geschirmte Leitungen verwenden. 
Damit sollte die 10-100 fache Geschwindigkeit drin sein.

Die Nachrichten werden mit 4 Parity Bits gegen Bitkipper gesichert.

In der angehängten Zip-Datei finden sich 3 Arduino-Dateien:
- MyCAN
- ID_EEPROM
- Test_MyCAN_V1

MyCAN

ist die Bibliothek für den modifizierten CAN-Bus. Stehen etliche 
Kommentare drin. Die wichtigsten Funktionen sind:

MC_setup()
Initialisierung der Pins und Interrupts (für Empfang)

MC_sendMessage()
Nachricht senden

MC_getMessageFromRXqueue()
Nachricht aus der Queue holen

MC_printStats()
Statistik zu Sendung und Empfang über RS232 ausgeben

Für jede Nachricht wird eine unsigned long variable verwendet. Der 
Empfang läuft per Interrupt im Hintergrund. Die selbst gesendet 
Nachrichten werden quasi ebenfalls empfangen. Zum Abholen der 
Nachrichten ruft man MC_getMessageFromRXqueue auf. Alle noch nicht 
abgeholten Nachrichten stehen in einem Array mit Platz für 32 
Nachrichten.

Der Ganze Rest wie kodieren, dekodieren, Parity berechnen und prüfen 
läuft alles im Hintergrund.

Um eine eindeutige ID für jeden Teilnehmer zu generieren und speichern 
habe ich noch die Bibliothek ID_EEPROM angehängt. Diese generiert durch 
Auslesen von 8 Analogpins eine "zufällige" Zahl, berechnet daraus eine 
ID zwischen 0 und 63 und speichert sie zusammen mit einem Code im 
EEPROM. Beim ersten Aufruf von ID_getID() geschieht dies. Bei jedem 
weiteren Aufruf von ID_getID() wird die gespeicherte ID ausgegeben, auch 
bei Verlust der Versorgungsspannung.

Damit kann man ganz prima Sensoren mit IDs versehen.

Zuletzt ist als Beispiel die Arduino Datei Test_MyCAN_V1 angehängt. 
Diese initialisiert die Kommunikation und verschickt Nachrichten mit 
einer kleinen Rechenübung. Nach Empfang wird die Rechnung nachvollzogen 
und geprüft. So läßt sich testen ob Parity gereicht hat.

Mit dem Programm kann man mit 3-4 Teilnehmern eine Art Stresstest 
aufbauen. Ein exemplarisches Ergebnis hänge ich noch mit an.

Ich hoffe, der eine oder andere kann das Ganze gebrauchen und stehe 
gerne für Fragen zur Verfügung!

Viele Grüße,
André.

: Bearbeitet durch User
von Andre B. (andrebx)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft 
;-)

von Bernhard R. (bernhard_r874)


Bewertung
3 lesenswert
nicht lesenswert
Warum keine Standard CAN Transceiver verwenden?
Differentielle, störunanfällige Übertragung + Absicherung gegen 
Überspannung und Transienten...

Interessanter "proof of concept" aber IMHO in der Praxis so nicht 
einsetzbar

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andre B. schrieb:
> - Prioritätssteuerung der Nachrichten nach ID
> - Multi-Master-System: alle können gleichzeitig senden
> - Fehlerkontrolle per Parity Bits

Dazu fällt mir als Frage ein wie das ohne dedizierte Unit funktionieren 
können soll ohne den Controller zu 100% auszulasten.

Aber sonst ja, gibt doch schon CAN.

von MiWi (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Andre B. schrieb:
> Hallo zusammen,
>
> keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft
> ;-)

Was soll man dazu sagen? Wenn es für Dich funktioniert, fein und es ist 
Anerkennenswert, daß Du eine neue Lösung für ein schon seit sehr langem 
gelöstes Problem erdacht hast.

Jeder Huster im Haus oder ums Haus wird Deine Kommunikation 
durcheinander bringen, das ganze ist massiv von den Kabelkapazitäten 
(Leitungslänge) abhängig, wenn der Pullup als Gegenmaßnahme zu 
niederohmig wird dann klingelt es an allen Ecken und Enden mehr als den 
angeschlossenen Halbleitern lieb ist, der Aufwand das in den Griff zu 
bekommen ist auch nicht gerade gering, Störfestigkeit läßt sich 
Konzeptbedingt nur durch geringere Baudrate erreichen...

OpenCollectordinge sind vor gefühlten 70 Jahren erfunden worden und es 
hat einen Grund, warum für lange Leitungen (und Hausbusse haben solche) 
normalerweise differentielle Signale oder "hf" verwendet wird

Bei mir reichen 3pol Kabel auch für die CAN-Verbindung, die in vielen 
Bereichen (SW, HW, Konzept) robuster ist.



MiWi

von temp (Gast)


Bewertung
6 lesenswert
nicht lesenswert
Ich schließe mich den Kritiken an. Seit ich CAN verwende will ich nichts 
anderes mehr haben. Vor allem auch weil man sich um das 
Hardwareprotokoll nicht kümmern muss.
Die erste Hardwarekrücke hast du ja schon in MyCan eingebaut. Wenn der 
linke Controller im Reset ist wird der Bus Low und nichts geht mehr. 
Sowas will keiner haben. Und wenn jetzt noch ein paar Bauteile mehr dazu 
kommen ist auch der Platz für den Treiber größer als ein 
CAN-Transceiver. Was soll das also für einen Nutzen bringen?
Bei einem Hausbus sollte man auch nicht glauben die Baudrate spielt 
keine Rolle. Klar für einen Temperatursensor allein nicht, aber wenn da 
noch etwas Photovoltaik, Heizung, Wärmepumpe u.s.w. dazukommen sind das 
schnell mal ein paar 100 Byte pro Sekunde. Am Ende wird es dann doch 
wieder auf verdrillte Leitungen hinauslaufen und die haben im minimum 2 
Paare von denen man 2 für die Versorgung von kleinen Knoten nehmen kann. 
EIB-Kabel sind da nicht die schlechteste Lösung.
Wenn deine Lösung bei einer bestimmten Baudrate in beliebiger Topologie 
und mit beliebigen Leitungen funktioniert funktioniert sie mit einem 
ordenlichen CAN-Transceiver erst recht. Ich benutze 100k weil meine 
LPC11C24 das als Bootloaderbaudrate haben. Um die Topologie habe ich mir 
keine Gedanken gemacht und auch 1984 verlegte unverdrillte 
Telefonleitungen mit verwendet. Bisher ohne irgendwelche Probleme.

von Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)


Bewertung
1 lesenswert
nicht lesenswert
Warum nicht LIN mit eigenem Protokoll?

von Thomas F. (igel)


Bewertung
1 lesenswert
nicht lesenswert
Andre B. schrieb:
> Es wird für einen Arduino insgesamt also eine 3-adrige Leitung benötigt
> (5V, Gnd, Signal).

Warum keinen 1-Draht-CAN?

Transceiver für 1-Draht-CAN
http://www.nxp.com/docs/en/data-sheet/MC33897.pdf

Dann hat man Arbitrierung, Kollisionsvermeidung und Fehlerüberwachung 
gleich in Hardware im Controller.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Seit ich CAN verwende will ich nichts
> anderes mehr haben. Vor allem auch weil man sich um das
> Hardwareprotokoll nicht kümmern muss.

Ich kann mich da nur anschließen.
CAN ist sowas von problemlos, einfach und zuverlässig.

Der einzige Nachteil von CAN ist, daß Atmel nur wenige MCs mit CAN im 
Programm hatte (AT89C51CC03, AT90CAN128). Und die ATmega64C1 waren lange 
Zeit schwer zu beschaffen.

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:

> Der einzige Nachteil von CAN ist, daß Atmel nur wenige MCs mit CAN im
> Programm hatte (AT89C51CC03, AT90CAN128). Und die ATmega64C1 waren lange
> Zeit schwer zu beschaffen.

Dafür haben Renesas und Freescale umso mehr.

von Achim.S (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andre B. schrieb:
> Um eine eindeutige ID für jeden Teilnehmer zu generieren und speichern
> habe ich noch die Bibliothek ID_EEPROM angehängt. Diese generiert durch
> Auslesen von 8 Analogpins eine "zufällige" Zahl, berechnet daraus eine
> ID zwischen 0 und 63 und speichert sie zusammen mit einem Code im
> EEPROM

Wie vorhersagbar ist das denn? Und wie groß ist die Chance, dass von 10 
Geräten 2 die gleiche ID haben?

Da wäre mir die Adressierung wie bei I2C lieber (ein paar Bits für den 
Typen und ein paar Bits per Dipschalter)

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Andre B. schrieb:
> keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft
Man kann ein CAN-Protokoll auch ohne CAN-Transceiver als Eindrahtbus 
fahren. Allerdings vergibt man damit die Störsicherheit, die der 
differenzielle Bus bringt.
Und man vergibt sich die Möglichkeit, einen simplen CAN-Sniffer 
anzuschließen und mal am Bus mitzuhören.

Achim.S schrieb:
> Und wie groß ist die Chance, dass von 10 Geräten 2 die gleiche ID haben?
Mit etwa 52%. Das gilt als "fast sicher"... ;-)
Siehe https://de.wikipedia.org/wiki/Geburtstagsparadoxon

: Bearbeitet durch Moderator
von Andre B. (andrebx)


Bewertung
0 lesenswert
nicht lesenswert
Oha, viel Kritik, kann ich aber mit umgehen ;-)

Ein paar Kommentare:
- CAN scheidet für mich komplett aus, weil ich unter anderem völlig 
ungeschirmte und unverdrillte Strom-Erdkabel zur Kommunikation 
mißbrauche.
- Statt CAN-Controller brauche ich einen Transistor pro Slave - weniger 
geht nicht
- Hier bringt kein Huster nix aus dem Tritt ;-)
- Die zufällig generierten IDs sind nur Hilfsmittel ums einfacher zu 
machen. Wer zu viele Teilnehmer hat kann die auch manuell vergeben
- Reset eines Teilnehmers unterbricht die Kommunikation tatsächlich für 
ein paar ms. In meiner Hausautomatisierung kein allzu großes Problem

Dachte hier wären ein paar mehr Leute die Spaß am Basteln und 
Selbermachen haben, aber da bin ich wohl alleine...

Viele Grüße,
André.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andre B. schrieb:
> keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft

Andre B. schrieb:
> Oha, viel Kritik, kann ich aber mit umgehen ;-)

Andre B. schrieb:
> Dachte hier wären ein paar mehr Leute die Spaß am Basteln und
> Selbermachen haben, aber da bin ich wohl alleine...

Irgendwie bist du hier falsch.

Georg

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Dachte hier wären ein paar mehr Leute die Spaß am Basteln und
>Selbermachen haben, aber da bin ich wohl alleine...

Vielleicht hättest du das ohne Arduino machen sollen. Nicht jede mag das 
Zeugs.

MfG Spess

von temp (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Andre B. schrieb:
> - CAN scheidet für mich komplett aus, weil ich unter anderem völlig
> ungeschirmte und unverdrillte Strom-Erdkabel zur Kommunikation
> mißbrauche.

Bist du ernsthaft der Meinung deine Transistortreiber gehen und CAN auf 
der gleichen Leitung mit der selben Baudrate geht nicht? Ich denke dann 
bist du komplett auf dem Holzweg. Ob das konform mit den Spezifikationen 
ist interessiert hier recht wenig. Dein Bus hat auch keine 
Spezifikation.

> - Statt CAN-Controller brauche ich einen Transistor pro Slave - weniger
> geht nicht

Aber nur wenn die Slaves ausschließlich senden sollen. Wenn auch Empfang 
angedacht ist, sollten wohl noch ein paar Bauteile vor den Eingangspins 
kommen. Oder soll der völlig ungeschützt am Bus lauschen?

> - Hier bringt kein Huster nix aus dem Tritt ;-)

ne, aber in die ewigen Jagdgründe!

Bei der Preisbetrachtung kommt noch der Zeitaufwand für das Protokoll 
dazu. Da spielen die paar Euro für die CAN-Hardware am Ende keine Rolle 
mehr.

Andre B. schrieb:
> Dachte hier wären ein paar mehr Leute die Spaß am Basteln und
> Selbermachen haben, aber da bin ich wohl alleine...

Wir gehören nicht zu den Millionen Fliegen die Scheiße gut finden...

von Fabian (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Can auf Erdkabel geht garantiert besser als deine Lösung auf Erdkabel. 
;-)

von Fabian (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wie genau werden die Leitungen denn an den µC angebunden? - Deine 
Zeichnung gibt kein Hinweis auf die getroffenen ESD - Maßnahmen (gegen 
Burst & Surge).

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> den Bus gegen Low ziehen kann (dominant). Die Information selbst wird
> anders als bei CAN über die Länge des Pulses dargestellt. Eine logische
> "1" ist ein kurzer Puls, eine logische "0" ein langer.

Das ist genau so ein Mist wie 1-Wire. Wenn du ein Protokoll nutzt wo 
sich der Lowlevel nicht mit gaengigen USARTs abbilden laesst dann 
muessen deine Controller die Kacke immer am Dampfen halten und sie nicht 
im Sleepmode.

Olaf

von kyrk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ohh ja, 1-Wire :) Wo man so zwischen 480us und 8us (oder so) Pulsezeiten 
einhalten muss. Mit NOP-s ist 480us zu lange. Mit Timers+Interrupt ist 
der 8us zu kurz.

von X4U (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Andre B. schrieb:
> Die Datenleitung wird über einen Pullup gegen Hi gezogen. Dies ist der
> rezessive Zustand. Jeder Busteilnehmer verfügt über einen Transitor, der
> den Bus gegen Low ziehen kann (dominant). Die Information selbst wird
> anders als bei CAN über die Länge des Pulses dargestellt. Eine logische
> "1" ist ein kurzer Puls, eine logische "0" ein langer.

Welche Vorteile hat das gegenüber einer etablierten seriellen 
Kommunikation wie z.B. RS232 und einer darauf aufbauenden Busversion wie 
z.B. LIN?

Da gibt es fertige Treiber, Testgeräte wie Protokollanalyser auch im 
Soho Bereich, Programmbeispiele und und und ... es funktioniert.

Ein eigenes System muss da schon etwas bieten worauf keiner der Gurus 
gekommen ist.

Nachteile sind aber einige da. Z.B. dass sich mit deinem Protokoll die 
Flankenwechsel verdoppeln (und die Bitrate sich halbiert) ohne etwas zu 
gewinnen. Leitungen sind ja auch immer Antennen, das ist nicht gerade 
störstrahlfreundlich.

von Bad U. (bad_urban)


Bewertung
0 lesenswert
nicht lesenswert
Deine Initiative ehrt dich ja. Und es macht ja auch Spaß was eigenes zu 
entwickeln und sich Gedanken darüber zu machen. Geht mir ja genauso :)

Vieles wurde ja auch schon geschrieben.

Einen Punkt wollte ich aber noch zu bedenken geben, der bei meiner 
Hausautomatisierung eine wichtige Rolle gespielt hat.

Da die Knoten ja meist "versteckt" sind war es für mich wichtig einen 
Bootloader zu haben mit dem ich die Firmware über den Bus updaten kann.

Andre B. schrieb:
> Message Structure
>   ID Value Parity
>   10   16     4 Bits = 30 Bits
>  3FF  FFFF    Maximalwert
>
> Damit können nur etwas 5 Nachrichten pro Sekunde verschickt werden.

Das wären dann grade mal 10Byte Payload/s. Da würde ein Update ewig 
dauern.
Für einfache Sachen wie Licht ein/aus reicht das sicher. Aber schon wenn 
man an Funktionen denkt wie "Zentralaus" wo beim betätigen eines Tasters 
mehrere Aktionen ausgeführt werde und mehrere Telegramme zu versenden 
sind bekommst Du da schon ein ziemliches Delay.

Olaf schrieb:
> Wenn du ein Protokoll nutzt wo
> sich der Lowlevel nicht mit gaengigen USARTs abbilden laesst dann
> muessen deine Controller die Kacke immer am Dampfen halten und sie nicht
> im Sleepmode.

Da sehe ich kein Problem. Bei Pulsdauer 4/8ms hast Du genug Zeit den 
Controller per Interrupt beim Flankenwechsel zu wecken.
Das ist eher ein Problem bei CAN. Wenn man hier den Transceiver 
deaktiviert (der oft der größte Verbraucher in der Schaltung ist) ist 
die Nachtricht futsch bis alles aktiviert ist.

: Bearbeitet durch User
von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Bad U. schrieb:
> Bei Pulsdauer 4/8ms hast Du genug Zeit den
> Controller per Interrupt beim Flankenwechsel zu wecken.

Das 1-wire-Protokoll läuft in µs, nicht ms - hatte mich auch etwas 
ausgebremst, daß Das so flott sein muß.
Unterm Strich wurden per Schleifen Takte totgeschlagen - da man 
taktgenau berechnen kann, wie lange eine Schleife dauert, kommt man so 
ganz gut parat.
In der Zeit macht der Rechenknecht halt Nichts Anderes - zum Auslesen 
von DS18B20 aber 'ausreichende Technik'.

Müsste nachlesen, aber Das hier:

kyrk schrieb:
> 8us

dürfte den realen Werten recht nahe kommen.

MfG

von Andre B. (andrebx)


Bewertung
0 lesenswert
nicht lesenswert
> Aber nur wenn die Slaves ausschließlich senden sollen. Wenn auch Empfang
> angedacht ist, sollten wohl noch ein paar Bauteile vor den Eingangspins
> kommen. Oder soll der völlig ungeschützt am Bus lauschen?

Ich verwende einen modernen Mikrocontroller, der hat ESD-Schutz an jedem 
Pin ;-)

> ne, aber in die ewigen Jagdgründe!

Warum noch mal?

> Wir gehören nicht zu den Millionen Fliegen die Scheiße gut finden...

Sehr robuste Töne von Dir. Sehr subtil ;-) Aber jeder muss selbst 
wissen, wie er sich auszudrücken wählt.

Insgesamt kann ich nur feststellen, dass es für mich die einfachste 
Lösung war. 1 Transitor plus pro TN bisken SW die meinen uC kaum 
belastet, absolut robuste Übertragung die seit Monaten fehlerlos läuft 
und klar - schnarchlangsam, aber wie gesagt für meine Anwendung absolut 
ausreichend. An meine uCs komme ich fürn update per USB dran, und über 
50m Netzleitungs-Erdkabel gehen ohnehin keine großen Datenraten.

Ich hatte meinen Spaß damit und wer ein wenig basteln und lernen möchte 
wie eine einfache aber robuste Kommunikation funktioniert findet 
vielleicht auch gefallen dran.

von Marc H. (marchorby)


Bewertung
-2 lesenswert
nicht lesenswert
spess53 schrieb:
> Vielleicht hättest du das ohne Arduino machen sollen. Nicht jede mag das
> Zeugs.

Wer AVR verwendet aber kein Arduino mag, ist meiner Meinung nach 
dämlich! Ein Ardunino ist nichts anderes als ein AVR mit nem Bootloader 
auf einem Breakoutboard gelötet. Man muss ja nicht die IDE nehmen! Und 
bei den Preisen nehmen wir sogar Arduino-Boards und verkabeln sie 
passend mit den Sensoren um zu schaun ob das ganze so läuft. Danach wird 
eine PCB designt. Wir sparen damit ungeheure Zeit. Und was Zeit im 
Business bedeutet muss man hoffentlich nicht erläutern!

Aber lasst die Arduino-Nichtmöger ruhig weiter erstmal PCBs ätzen um 
dann festzustellen das sie einen Pinfehler drinn haben ;-)

von Bad U. (bad_urban)


Bewertung
0 lesenswert
nicht lesenswert
Patrick J. schrieb:
> Das 1-wire-Protokoll läuft in µs, nicht ms

Ich hatte das ja auf dem Bus vom TO bezogen, nicht auf 1-Wire.

Andre B. schrieb:
> Insgesamt kann ich nur feststellen, dass es für mich die einfachste
> Lösung war.

Dann passts doch :)
Klar wenn Du nur ein NYY mit drei Adern hast geht die Kommunikation halt 
nur mit zwei Adern. Gibts, wie geschrieben bei CAN aber auch.

Und ob das auch sicher mit

Andre B. schrieb:
> beliebigen
> auch ungeschirmten Leitungen und Topologien funktioniert.

kann sein, aber was bringt Dich zu der Annahme?

Wenn man nur auf Vorhandenes zurückgreifen kann ist die Lösung ja OK.
Du schreibst aber auch, dass Deine Idee eine Erweiterung Deiner 
Hausautomatisierung ist. Die wäre vielleicht für das Forum wesentlich 
interessanter.

: Bearbeitet durch User
von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wer AVR verwendet aber kein Arduino mag, ist meiner Meinung nach
>dämlich!

Deine Meinung.

>Und was Zeit im Business bedeutet muss man hoffentlich nicht erläutern!

Doch müsstest du. Bei uns in der Firma geht es jedenfalls recht 
entspannt zu.

>Aber lasst die Arduino-Nichtmöger ruhig weiter erstmal PCBs ätzen um
>dann festzustellen das sie einen Pinfehler drinn haben ;-)

Wir machen keine Leiterplatte mehr. Ein paar Musterleiterplatten sind 
halt billiger als eine komplette Galvanik und den ganzen Zirkus den man 
für mehrlagige Leiterplatten drumherum braucht.

Außerdem ist ein richtige Leiterplatte selbst mit ein paar kleineren 
Fehler immer noch sicherer als so ein zusammengeschusterter 
Lego/Duplo-Aufbau aus irgendwelchen Breakout-Boards.

Ich mache beruflich seit 20 Jahren Leiterplattenlayouts und auch die 
passende Software dazu. Mit Elektronik und Programmierung habe ich schon 
einige Zeit früher angefangen.

Also ich bin glücklich dieses Arduino-Gedödel nicht zu brauchen. War ja 
ursprünlich auch mal für Künstler und ähnlich nicht eleketronikaffine 
Leute
gedacht.

Dämlich sind die, die Arduino benutzen, weil sie nichts anderes können.

MfG Spess

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


Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Dämlich sind die, die Arduino benutzen, weil sie nichts anderes können.

 Wir sind zwar auf ARM umgestiegen, benutzen aber immer noch Arduino
 Pro-Mini und Nano Clones als Slaves für STM32 und sind sehr zufrieden
 damit. Haben noch eine ganze Menge davon, zusammen mit passenden
 Modul-Boards dafür. Die kleinen Dinger sind zuverlässig und im
 Gegensatz zu manch anderen Arduino-Boards ist Layout auch gut.
 Für verschiedene Low-Level Aufgaben, noch dazu im Assembler
 programmiert, gibt es einfach nichts besseres.

> Außerdem ist ein richtige Leiterplatte selbst mit ein paar kleineren
> Fehler immer noch sicherer als so ein zusammengeschusterter
> Lego/Duplo-Aufbau aus irgendwelchen Breakout-Boards.

 Nein, nicht immer.
 Auch wenn ich mich wiederhole:
 Beim PC mit 3-4GHz wird auch vieles gesteckt bzw. mit Kabeln
 verbunden, es funktioniert und es stört sich keiner dran - warum
 sollten Arduino-Boards mit lächerlichen 16MHz nicht steckbar sein ?

: Bearbeitet durch User
von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Beim PC mit 3-4GHz wird auch vieles gesteckt bzw. mit Kabeln
> verbunden, es funktioniert und es stört sich keiner dran - warum
> sollten Arduino-Boards mit lächerlichen 16MHz nicht steckbar sein ?

Bis auf Stromversorgung sind das standarisierte erprobte Schnittstellen. 
Wo sollten da Probleme herkommen

>Die kleinen Dinger sind zuverlässig und im
> Gegensatz zu manch anderen Arduino-Boards ist Layout auch gut.

Also ist Arduino Board nicht gleich Arduinoboard. Oder sehe ich das 
falsch. Abgesehen davon wurden hier mehr irgend welche 
Sensor-Breakout-Boards favorisiert.

MfG Spess

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


Bewertung
1 lesenswert
nicht lesenswert
spess53 schrieb:
> Also ist Arduino Board nicht gleich Arduinoboard. Oder sehe ich das
> falsch.

 Also, R3 Boards würde ich wegen Raster und fehlerhafter Stromversorgung
 bzw. Abblockung niemals verwenden.


> Abgesehen davon wurden hier mehr irgend welche
> Sensor-Breakout-Boards favorisiert.

 Tja, schlecht und billig - aber solange es für Eigengebrauch ist...
 Es gibt ein russisches Sprichwort, in etwa heisst es:
 Käse umsonst gibt es nur in der Mausefalle.

 Irgendwie trifft das auch auf diese Breakout Boards aus China zu...

von temp (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Andre B. schrieb:
> Ich verwende einen modernen Mikrocontroller, der hat ESD-Schutz an jedem
> Pin ;-)

Du beliebst zu Träumen. Der eingebaute ESD Schutz genügt maximal um 
statische Aufladungen beim Anfassen zu händeln. Mag sein dass das bei 
dir bisher gut ging aber verallgemeinern kann man das auf keinen Fall.

>
>> ne, aber in die ewigen Jagdgründe!
>
> Warum noch mal?

Weil dein Pin weitgehend ungeschützt an der langen Leitung hängt. Kannst 
ja damit mal in das nächste EMV Labor zum fröhlichen Pin braten gehen. 
Das allerwenigste ist ein Serienwiderstand um die Ströme in den 
Ableitdioden zu begrenzen. Und selbst das ist kein Schutz mehr wenn die 
beim EMV-Test  üblichen 8kV an 150pF auf deinen Eingang geschaltet 
werden. Aber 1000 mal besser als den Pin direkt auf die Leitung zu 
legen.

von Stromspiegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moins,

hier hacken viele auf Andre rum, vermutlich ohne eigene Erfahrungen 
gemacht zu haben. Darum teile ich mal meine:

Seit vier Jahren habe ich einen ähnlichen Bus laufen: drei Leitungen 
(+5V,GND,Signal), wobei das Signal an einer Stelle (derzeit alles andere 
als zentral) über einen Stromspiegel auf 5V gezogen wird -- anfangs 
hatte ich einen Pullup, das ging auch. Derzeit ca. 75m Leitung, fast 
alles 4x2-adriges Telefonkabel, das bereits in der Wand lag.

Ich fahre mit 3,3kBaud (also keine unterschiedlichen Bitzeiten), nutze 
ein paar CAN-Prinzipien. Die bisher vorhandenen vierzehn Geräte 
übertragen üblicherweise weniger als 400 Bit pro Sekunde (über fünf 
Sekunden ermittelt), da habe ich also noch viel Luft. Probleme gab es 
bisher keine.
Die Prozessoren (ATMega) langweilen sich, denn mit einem Capture-Eingang 
und einem Compare-Ausgang kann man das Protokoll ohne viel 
Rechenleistung umsetzen und auch noch das tun, was das Gerät eigentlich 
machen soll.

Natürlich gibt es jeden Monat ein paar Datenpakete, die nicht fehlerfrei 
überall ankommen, aber damit muss jeder Bus umgehen können, dafür gibt 
es CRC etc.

Die Hardware ist wirklich einfach, man braucht an jedem Busknoten weder 
Spezialbauteile noch lokale Spannungsregler, sondern nur sehr wenig 
diskretes Zeug außer dem Controller.

Gruß!

von Stromspiegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu meinem vorigen Beitrag:
natürlich ist ein solcher Bus keine Lösung für jedes 
Kommunikationsproblem und hat seine besonderen Vor- und Nachteile -- 
aber das gilt auch für jeden anderen.

von Harald (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Na ja, es ging von André so ein bisschen in die Richtung, dass CAN ja 
ausscheidet, weil das auf dem Kabel ja nicht funktionieren würde. DARAUF 
sind einige Leute (zu Recht) eingestiegen. Vielleicht war es die 
Fehlannahme, dass CAN-Leitung geschirmt und verdrillt sein müsste.

"MiWi" und "temp" haben das am 05.07. um 09:14 und 09:51 ganz gut 
zusammengefasst und ich kann mich dem nur anschließen: Es kann ja für 
ihn in seinem Umfeld funktionieren, eine brilliante Lösung ist es 
dadurch nicht.

Der vermeintlich einfache Anschaltungsaufwand würde sich im nächsten 
Anwendungsszenario bei einem anderen Anwender rächen, z.B. wenn 
Störquellen vorhanden sind.

Der Basteltrieb in Ehren und André hat bestimmt auch etwas dabei 
gelernt. In vielen Beiträgen hier im Forum zeigen sich die verschiedenen 
Ausprägungen der Autoren. Die einen möchten "basteln" um jeden Preis, 
mit Breadboards, Pollin-Bauteilen, Arduino, uralten Controllerfamilien 
usw. Andere Poster möchten wiederum professionelle Elektronik verstehen 
und/oder entwerfen, die möglichst im höchsten Maße standardkonformen, 
zuverlässig und robust funktioniert - einfach nur so, auch ohne direkte 
Notwendigkeit.

Da gibt es zwischen diesen Lagern keinen Konsens, niemals leider.

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.