Camping Interface - fpc, arduino, LIN- Bus

[af0815]

Wie schon in einem anderen Thread angekündigt (viewtopic.php?f=9&t=12406) möchte ich mich für den Wohnwagen mit einem einfachen, stromsparenden Gerät auseiandersetzen, das ich mit dem FPV/Lazarus auch programmieren kann.

Mein erster Versuch geht in Richtung Batterieanzeige.

Dazu habe ich mich ein bischen mit der Materie befasst und mich entschlossen mit einem Arduino Uno und einem Standardbauteil für die Batterieüberwachung die ersten Versuche zu machen. Für den Sensor möchte ich mir den Dometic Batteriesensor PerfectCharge MCA-HS1 besorgen, dieser dürfte auf dem Hella IBS basieren der über den LIN-Bus angebunden wird.

LIN-Bus ist mit dem Arduino man grundlegend machbar. Es gibt die diversesten Ansätze dazu. Da ich für meine Versuche soweit wie möglich mal mit Standardbausätzen arbeiten will, habe ich mir bei RS die ATA6629-EK Microchip Technology ATA6629-EK Entwicklungsplatine, LIN-Transceiver herausgesucht. Damit will ich die grundlegende Spezifikation des Buses einzuhalten und mich auf das Protokoll beschränken. Ev. hilft mir APGDT001 Microchip - LIN Serial Analyzer APGDT001 Entwicklungskit, LIN-Bus auch dabei. (Wennschon, dennschon )

Für den LIB-Bus der im Automotive Segment ist, gibts sicher eine Menge an Sensoren, auf die man dann zugreifen kann. Temperaturfühler habe ich schon ausgemacht und weitere Komponenten werden folgen. Der Vorteil, die Komponenten sind dann für das Umfeld im Wohnwagen bereits richtig ausgelegt und ich brauche mich mit Störungen etc. nicht auseinandersetzen.

Und wenn es nichts wird, dann habe ich wieder Erfahrung gewonnen Erst wenn ich auf den Prototypen weiterkomme, denke ich über eine eigene Platine nach die dann sicher an den Wohnwagen angepasst wird.

Andreas

[Timm Thaler]

Für den Sensor möchte ich mir den Dometic Batteriesensor PerfectCharge MCA-HS1 besorgen

Dein Ernst? Das Teil kostet um die 100 Eur.

Für den LIB-Bus der im Automotive Segment ist, gibts sicher eine Menge an Sensoren, auf die man dann zugreifen kann.

Das Problem bei allen diesen Automotive-Sensoren ist: Die sind halt schweineteuer. Also wenn Du aufs Geld nicht achten musst, ok, aber mir wäre das nichts, mein Geld den Automotive-Lieferanten für ihr überteuertes Zeug in den Hintern zu blasen.

Nachteil von LIN: Jeder, aber auch jeder Sensor muss LIN können. Mal eben einen HTU21 Temperatur+Feuchtesensor dranhängen ist dann nicht. Da wäre ein I2C Bus besser (Ja, der I2C schafft auch mehrere Meter bei niedrigerer Datenrate). Vorteil von LIN gegenüber I2C: Der größere Spannungshub und eine Leitung weniger.

[af0815]

Der IBS macht eine permenente Überwachung und weis genau was mit der Batterie los ist. Mir kommt es auf 100 Euro nicht an, wenn der Sensor was bringt. Vor allen, bei den meisten Ideen die ichgefunden habe wird es auch kompliziert, entweder du siehst nur die grossen Ströme über einen Shunt oder überwachst die Spannung. Dazu noch die ganzen Schutzbeschaltungen und Aufwand für Print und du bist auch mal gleich auf dem Preis.

Was bei dem Versuch auch wichtig ist, wenn ich den Sensor flott bekomme, kann ich weitre Sensoren auch selbst als Sensor aufbauen und an den Bus bringen.

[pluto]

Vielleicht wäre Tinkerforge was für dich?
Ist eine Deutsche Firma, die einen Bausatz anbietet.. Für mich sind sie einfach zu teuer und zu eingeschränkt, sie bieten aber sehr viele einfache Möglichkeiten an.
Leider braucht man dazu zweigend ein PI oder ähnliches. Sie bieten dazu den Red-Brick an.

Das könnte den Stromverbrauch deutlich erhöhen... Wäre aber recht einfach.... Mit Eingeschränkt meine ich z.b. zu meiner Zeit gab es einfach einige Dinge noch nicht, aber inzwischen wurde das Sortiment deutlich erweitert und es gibt eine Delphi/Lazarus Anbindung über eine API.

[af0815]

Nö. Tinkerforge ist nichts für mich.

Es geht mir um stabile Komponenten und ich muss nicht alles sebst basteln. Vor allen hat der IBS einiges drauf, das darf nan nicht vergessen. Vor allen wenn mein Projekt nichts wird, dann kann ich den mit einem Standardbaustein weiter verwenden.

Schau dir mal die Datenblätter für vom Hella an, wegen der Funktionen habe ich den Ausgewählt. Nicht weil er billig ist.

Edit: Siehe auch folgende Bericht(e)
https://www.campen.de/threads/604740-ba ... baubericht
https://www.hella.com/hella-at/assets/m ... nfo_de.pdf

[af0815]

Nachtrag, habe mir ein IBS gekauft

Hella Artikelnummer: 6PY 178 103-855 / 6PY 178 103-831 (Siehe auch https://www.hella.com/hella-at/assets/m ... nfo_de.pdf )

der hat mit dem Display neu etwas über 110 Euro gekostet. Da war aber alles dabei, wirklich alles. Sensor, Baterrieadapter (damit man die alte Schelle wieder nach dem Sensor montieren kann) Kabel, also wirklich alles. Einbau war super, aktuell nehme ich das originale Display, bis ich den LIN-Bus besser verstanden habe

Das IBS kann sogar auf eine SD-Karte im CSV Format die Infos speichern, wenn man will und vier Schaltausgänge hat es auch.

[pluto]

Das Gerät macht einen guten Eindruck.... habe mir die Daten nur grob angeschaut...

Klingt nicht schlecht... Zum LIN Bus habe ich folgende Sachen gefunden.
https://www.mikrocontroller.net/topic/458048
https://github.com/macchina/LIN

Vielleicht gibt es auch schon Fertige Sachen, die man erst mal testen kann ob das Signal abgegriffen werden kann, dass ist ja dein Ziel oder?

[sstvmaster]

Hier gibts unter "Downloads" (runter scrollen) ein zip mit Pascal, Exe und Demos.

https://www.peak-system.com/PLIN-API.444.0.html?&L=1#

[af0815]

Hier gibts unter "Downloads" (runter scrollen) ein zip mit Pascal, Exe und Demos.

https://www.peak-system.com/PLIN-API.444.0.html?&L=1#

Code: Alles auswählen

The PLIN-API is designed to be used exclusively with a PC LIN interface from PEAK-System.

Ist ausserdem PC und nicht Arduino (oder ATMEGA328P)

@Pluto: Ja, ich kenne mittlerweile so ziemlich alle Artikel zu LIN im Netz . Das ist aktuell nicht so ganz mein Problem. Sondern der Arduino hat nur einen UART. Fürs Debuggen muss ich mir irgendwie was schaffen, damit ich sehe wo es krankt. Denn den UART brauche ich für den LIN. Nur es ist nicht ganz so einfach, da bei LIN eine Syncsequenz gesendet werden muss, damit sich die Slaves syncen können. Diese Sequenz zu erstellen, geht aber mit dem UART nicht, das muss man 'zu Fuß' machen.

Wäre ja alles nicht sooooo schlimm, aber ich will das ganze mit Pascal (mit Assemblerunterstützung) machen. Und da brauche ich noch einiges an Zeit um mich da ein zu arbeiten. Das ist mein Hauptproblem.

[sstvmaster]

Ist ausserdem PC und nicht Arduino (oder ATMEGA328P)

Das ist schon richtig. Ich dachte es ging dir auch darum das Protokoll zu verstehen. Ob das nun vom PC oder Arduino ist sollte doch egal sein. Das Potokoll ist doch das selbe.

[af0815]

Ist ausserdem PC und nicht Arduino (oder ATMEGA328P)

Das ist schon richtig. Ich dachte es ging dir auch darum das Protokoll zu verstehen. Ob das nun vom PC oder Arduino ist sollte doch egal sein. Das Potokoll ist doch das selbe.

Das Protokoll ist nicht das Problem, auch nicht die Implementation, wenn ich die Hardware mit der Programmierung im Griff habe. Wäre nicht das erste Protokoll das ich umsetze

Ich kämpfe mit den absoluten Basics des ATMEGA328P und Arduino. Programmer, Bootloader, ....

[jayway]

Du könntest zusätzlich zur "echten" UART an Pin 0 und 1 noch eine Software-UART an zwei anderen Pins laufen lassen. Oder: Für manche Dinge reicht ja manchmal auch ein "LED-Debugging", um zu sehen in welchem Programmteil man sich gerade aufhält. Hardwarealternative eventuell auch ein LCD, das braucht aber 6 Pins. Allerdings könnte es später auch andere Informationen ausgeben.

Gruß Jay

edit: Ein Simulator würde auch helfen. FP erzeugt ja Assembler-Code, den man vielleicht in einem Simulator zum Laufen bringen könnte. Es gibt da sogar einen, der mit Lazarus entwickelt wird.
http://www.avr-asm-tutorial.net/avr_sim/index_de.html

[af0815]

Du könntest zusätzlich zur "echten" UART an Pin 0 und 1 noch eine Software-UART an zwei anderen Pins laufen lassen.

Genaugenommen benötige ich nur eine 1 Pin Simulation (Ausgabe). Aktuell bin ich da mal dran, aber je mehr ich hineintauche umso mehr Fragen ergeben sich Da muss ich durch ein paar Grundlagen mal durch. Bootloader, C(++) in Pascal einbinden, .....

[jayway]

Ich habe hier noch die Quellen für eine S-UART in C. Ist zwar für den Atmega8, aber relativ schnell auf den 328p angepasst. Ich wollte mich jetzt ohnehin damit auseinandersetzen. Ich weiß nur nicht, wie das mit dem Timing auf einem Arduino funktioniert, da müsste ich mich auch weitergehend belesen. Ich glaube bei Arduino ist das ganze Interrupt-Handling stark abstrahiert.

Gruß Jay

[Timm Thaler]

Sondern der Arduino hat nur einen UART

Die max. 19200 Baud für LIN schafft ein ATmega mit 16MHz locker auch mit Software-Uart. Und davon kannst Du dann 2-3-4 Stück haben.

Ich weiß nur nicht, wie das mit dem Timing auf einem Arduino funktioniert, da müsste ich mich auch weitergehend belesen.

Da musst Du Dich jetzt mal entscheiden:

1. Arduino als Hardware-Plattform? Dann wäre das ein ATmega328 beim Arduino Uno. Mehr hat das mit Arduino nicht zu tun, vergiss den Rest den Du zu Arduino gelesen hast.
2. Arduino auch als Software-Plattform? Das wäre dann die Arduino-IDE, die Arduino-Libs und Programieren in Arduino-C. Hat dann aber mit Pascal nichts mehr zu tun.

Wenn Du nur 1. willst, dann brauchst Du Dir um "Timing", "Interrupt-Handling" wie es die Arduino-Software macht überhaupt keine Gedanken machen, denn: Die verwendest Du ja nicht. Wenn Du in Pascal programmierst, baust Du Dir Deine eigenen Timer, Interrupts, Port-Zugriffe, kannst Assembler einbinden. Dann programmiest Du nahe an der Hardware des ATmega328 und kannst das beliebig schnell machen.

Die Arduino-IDE brauchst Du nur noch, um das Programm physisch auf den ATmega328 zu schieben, oder Du nimmst AVRdude oder den AVR Burn-O-Mat.

Die Tuts von Mathias sind da ein guter Einstieg.