Zitat von MichaB im Beitrag #20Kurz noch eine Verständnisfrage zum DCC-Protokoll. Verstehe ich das richtig, dass man das als Alternative zu I2C nutzen kann?
Grundsätzlich ja, solange Du die Daten nur in eine Richtung übertragen willst. Das DCC-Protokoll benötigt auch nur eine Leitung ( neben Gnd natürlich ) und ist sicher problemloser auf größeren Leitungslängen. I2C ist allerdings bidirektional - Du kannst da also in beiden Richtungen Daten übertragen. Bei meinem - schon etwas länger existierenden - Bahnhof nutze ich auch I2C zur Kommunikation zwischen Stellwerk und Weichen/Signal-Steuerungen. Die längsten Leitungen sind da ca 4m lang. Ich benutze allerdings einen Busumschalter, so dass nicht immer alle Leitungen gleichzeitg am Bus hängen. Ein Hauptproblem bei I2C sind die Leitungskapazitäten. Die Lösung mit DCC hatte ich mal für das Bahnhofsmodul eines Mobakollegen realisiert. Da konnte man die Weichen dann wahlweise über das Stellpult ( wenn analog gefahren wurde ) oder auch per Umschaltung über dass DCC-Gleissignal ( wenn digital gefahren wurde ) steuern. Ich würde auf jeden Fall für die Kommunikation zwischen Stellpult und Weichensteuerungen ein Bus-System vorsehen. Das spart doch sehr viel Verdrahtung. Serial (zB. RS485) geht auch, hat aber bei den 'Standard' Arduinos ( UNO, Nano,Mini ) den Nachteil, dass sie neben der Schnittstelle für die Programmübertragung keine HW-serielle frei haben. Da müsste man das softwaremäßig lösen. Der Leonardo/Micro wäre da eine Alternative. Auch klein, aber mit einer freien seriellen HW- Schnittstelle.
Zitat von MichaB im Beitrag #20Ich habe es immer so gehandhabt: Entweder USB oder Fremdeinspeisung, das wolltest du damit doch sagen oder?
Ja, das geht natürlich immer. Ansonsten eben das USB-Kabel mit aufgetrennter 5V-Leitung. Das kann man grundsätzlich immer verwenden, wenn 'im System' programmiert werden soll.
Zitat von MichaB im Beitrag #20 zm Thema "Master" Arduinno komme ich,wenn ich meine Lösung hinsichtlich Stellpult vorstelle. Kurz noch eine Verständnisfrage zum DCC-Protokoll. Verstehe ich das richtig, dass man das als Alternative zu I2C nutzen kann?
Du kannst jede serielle Verbindung nutzen, die Master-Slave unterstuetzt, d.h. ein Master und ganz viele Slaves. Die Standard RS232 faellt da raus, das geht nicht (Betonung liegt auf Standard). Wenn man es wirklich so nennen will, etwas nachteilig ist dabei, dass Du immer einen Master hast, der die Slaves abfragen muss. Von der Hardware her waere das z.B. RS485, das ist stoersicher.
Du kannst auch CSMA/CD verwenden, das benoetigt keinen Master, alle auf dem Bus sind quasi gleichberechtigt. Das waere z.B. bei Ethernet und Loconet so.
Beim DCC hast Du wie gehabt das Problem mit den Rueckmeldungen, wenn Du das nur auf einer Verbindung machen moechtest.
Mir selbst schwebt ja eher etwas auf der Basis Raspberry mit spdrs60 vor. Da das bei diesem Wetter keinen Spass macht, das zukuenftige Hobbydomizil auszubauen, haenge ich eher am Rechner und mache mich da etwas mit der Steuerungstechnik von Modellbahnen vertraut. Dazu lese ich mich noch in Loconet ein.
Interessant ist heute auch die Verwendung von WLAN auf Basis des ESP8266, das erspart dann den kompletten Kabelverhau fuer den Datenbus und fuer kleine Schaltaufgaben genuegt bereits das ESP Node Modul, die gibt es unter 5 EUR. Die Dinger haben wirklich Charme! Und fuer die Steuerung einen Raspberry mit 7" oder 9" Touchdisplay.
Man hat heutzutage so viele Moeglichkeiten ...
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
Zitat von MicroBahner im Beitrag #19 P.S. @Tom Die Arduino Umgebung erleichtert zwar den Einstieg ungemein, verhindert aber bei eintsprechenden Kenntnissen keineswegs den Microcontroller bis aufs letzte Bit auszunutzen. Hinter der Arduino IDE steckt der GCC mit der AVR Toolchain, also letztendlich derselbe Compiler wie in AVR Studio. Allerdings sind dort die Debuggingmöglichkeiten ( mit entspr. HW ) wesentlich ausgefeilter.
Ja, das ist mir auch klar. Ich meinte mit "versteckt", dass man sich dann aber auch mit den Libs naeher beschaeftigen muss. Wenn man nun einige Jahre mit AVRs arbeitet, dann hat man fuer viele Standardsachen wie I2C, SPI, diverse LCD auch schon eigene Funktionen, die man kennt. Ich benutze das AVR Studio ganz selten mal in einer VM, meistens verwende ich den vim und avrdude oder Code::Blocks, wenn es Projekte mit mehr Umfang sind.
Dein Hinweis zu I2C mit den Leitungskapazitaeten ist gut! Das kann wirklich aergerlich sein, vor allem wenn man dann den Fall hat "Gestern hat noch alles funktioniert".
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
Schön Micha, das wird bestimmt ein interessanter Thread. Und Anfänger freuen sich bestimmt, dass du das Thema mal verständlich zusammen schreibst und ein Jeder mit dem Nachbau beginnen könnte.
Zitat von MichaB im Beitrag #1Der Servo muss an einen PWM-Pin (~, hier PIN 3) angeschlossen werden.
Ich bin mir gerade nicht sicher, da es davon abhängt wie die Servo Library arbeitet. Der PWM Pin wird immer dann benötigt, wenn man den Befehl analogWrite() nutzt. Damit kann man PWM Signale auf den Pin schicken und z.B. eine LED in der Helligkeit regulieren oder über einen Motortreiber die Motordrehzahl variieren. Aber meistens hat man ohnehin nicht die Probleme zu wenig PWM Pins zu haben, denn man benötigt auch anderweitig Eingänge und Ausgänge.
Zitat von dr iv im Beitrag #12Mir persönlich wären die Leitungen vom Prozessorpin zum Servo zu lang und somit u.U. zu störanfällig. Da bin ich auf Erfahrungen gespannt.
Ja, das stimmt. Es gibt auch immer mal Störungen. Die Leitungslängen sind nicht unerheblich. Ich würde eher dazu tendieren die Übertragung spannungsgeführt über Relais zu gestalten. Das benötigt natürlich einige Relais und der Stromverbrauch erhöht sich, allerdings benötigt das Relais eben auch deutlich mehr mA um anzuziehen als ein Port am Arduino.
Zitat von MichaB im Beitrag #1Der Servo muss an einen PWM-Pin (~, hier PIN 3) angeschlossen werden.
Ich bin mir gerade nicht sicher, da es davon abhängt wie die Servo Library arbeitet.
Weder die Servo-Lib der IDE, noch meine MobaTools benötigen PWM-fähige Pins. Bei beiden Libs werden die Servo Pulse per Timer-Interrupt softwaremäßig erzeugt. Das funktioniert an alllen dgitalen Pins ( auch an den analogen, die sich digital betrieben lassen - Also z.B. A0...A5 bei UNO/Nano )
Zitat von dr iv im Beitrag #12Mir persönlich wären die Leitungen vom Prozessorpin zum Servo zu lang und somit u.U. zu störanfällig. Da bin ich auf Erfahrungen gespannt.
Ja, das stimmt. Es gibt auch immer mal Störungen. Die Leitungslängen sind nicht unerheblich. Ich würde eher dazu tendieren die Übertragung spannungsgeführt über Relais zu gestalten.
Das verstehe ich nicht, wie Du die Servo-Anschlüsse über Relais realisieren willst. Auf meiner Moba ist die längste ServoLeitung ca. 3m lang, und ich hatte da noch keine Probleme. Allerdings ist das auch eine Ausnahme. In der Regel liegen die Leitungslängen unter 60cm. Mit dezentralen Mikrocomputern zur Ansteuerung ist das kein Problem. Man hat ja doch meistens mehrere Weichen und Signale die in einem solchen Umreis liegen.
Zitat von DL7BJ im Beitrag #23Dein Hinweis zu I2C mit den Leitungskapazitaeten ist gut! Das kann wirklich aergerlich sein, vor allem wenn man dann den Fall hat "Gestern hat noch alles funktioniert".
Die Kapazitäten können in der Tat tückisch sein. Das ist ja keine rein digitales (geht/geht nicht) Phänomen. Wenn man da nicht mit einem Oszi nachmisst, merkt man nicht, wenn man an die zulässige Grenze kommt. Und in dem Bereich hat man dann genau dieses Fehlerbild: mal geht's, mal geht's nicht.
also lag ich doch richtig, dass man für das Servo Signal keinen PWM Pin benötigt.
Nein, nicht die Servo Anschlüsse sollen über Relais realisiert werden, sondern die Kommunikation zwischen den Arduinos. Micha hat es so gebaut, dass ein Arduino der Master ist und die Befehle verwaltet die vom Stellpult kommen. Die anderen Arduinos arbeiten als Slave und sind unter den einzelnen Segmenten verbaut. Sie erhalten vom Master die Signale werten diese aus und schalten dann die Weichen. Vom Arduino zur Weiche gibt es keine Probleme. Aber eher bei der Kommunikation zwischen den Arduinos. Daher würde ich vom Master Arduino das Signal verstärkten und am Slave Arduino ein 5 V Relais einbauen. Das Relais wird auch über eine Entfernung von 10 m sicher schalten, da Störströme nichts ausmachen. Es braucht zum Anziehen einige mA. Am Wechselschalter des Relais kann man dann direkt den I/O vom Slave Arduino anschließen und hat wieder den H/L Pegel anliegen.
Ich habe auch so gut wie keine Probleme bei den Servos. Bei den Modulen schon gar nicht. Bei meiner Heimanlage war nur ein Weichenpaar zickig. Hier habe ich geschirmtes Kabel verbaut. Und dabei lag die Entfernung gerade bei etwa 1,5 m. Allerdings vorbei an Bahnstromleitungen usw.
Zitat von Dominik B im Beitrag #26Hallo Franz-Peter, Aber eher bei der Kommunikation zwischen den Arduinos. Daher würde ich vom Master Arduino das Signal verstärkten und am Slave Arduino ein 5 V Relais einbauen. Das Relais wird auch über eine Entfernung von 10 m sicher schalten, da Störströme nichts ausmachen.
Also das würde ich auf keinen Fall machen. Natürlich kann mann Arduinos auch über längere Leitungen zuverlässig über Datenbusse verbinden. Wie sollte DCC oder LocoNet funktionieren wenn das nicht ginge? RS485 wird mit Leitungslängen von mehreren 100 Metern zuverlässig betrieben. Und in unserem Umfeld bei überschaubaren Leitungslängen sollte sogar I2C eine Option sein.
Zitat von Dominik B im Beitrag #26 Nein, nicht die Servo Anschlüsse sollen über Relais realisiert werden, sondern die Kommunikation zwischen den Arduinos.
Parallel von Port zu Port? Das habe ich zuletzt vor 30 Jahren mit einer Siemens S5 gemacht, weil da genuegend Ports frei waren und die Kommunikationsmodule teuer.
Leute, sowas macht man nicht! Was ist das fuer eine Aufwand an Verkabelung und Relaistechnik? Und bei einer Stoerung sucht man sich dusselig! Beschaeftigt euch bitte mal mit einem stoersicheren Datenbus wie RS485. Aber auch Loconet waere hier die Loesung. Das ist einfach Stand der Technik zur Kommunikation zwischen Controllern oder auch zu Hostsystemen.
Fuer RS485 ist die erforderliche Hardware simpel und einfach. Einfach an die UART des Arduino einen LTC485 oder aehnliches, alles mit einer 2 Drahtleitung untereinander verbinden und etwas Software fuer ein Protokoll. Das kann man ganz einfach halten, wenn es nur um Weichen usw. geht, z.B. sendet der Mastercontroller im Stellpult <STX>W001<ETX> und schon schaltet der Controller auf der anderen Seite die Weiche 1. Das kann man simpel ausbauen, einfach nur kurze Textnachrichten, die man einmalig definiert.
Wenn man es nicht als Text machen will, kann man es auch mit einem Byte machen, schraenkt dann aber die Hoechstanzahl an Weichen auf 255 ein, das koennte knapp werden ;-)
Ich wuerde das so in der Art aufbauen:
<nnn> Adresse des Controllermoduls <x> Befehlsart <nnn> Adresse der Weiche, des Signals, Bahnuebergang usw. <nnn> Schaltbefehl
Am einfachsten geht das dann, wenn die Datentelegramme immer die gleiche Laenge haben, was aber nicht muss, wenn man noch ein STX an den Anfang setzt und ein ETX ans Ende.
<STX><001><R><ETX> waere dann z.B. eine Statusabfrage eines Controllermoduls. Mit der Antwort steuert man dann die LEDs im Schaltpult, das ist dann die Rueckmeldung.
<STX><001><S><001><001><ETX> wuerde dann Weiche 1 am Controller 1 schalten. Den Schaltbefehl koennte man auch fuer Links/Rechts nehmen, 1 ist links, 2 ist rechts usw.
Wenn man sich da einmal Gedanken macht, RS485 verwendet und die Basisroutinen mit der seriellen Schnittstelle in jedem Controller hat, dann laesst sich mit solch einem Aufbau schnell und simpel eine Bussteuerung aufbauen, die auch stoersicher ist. Wenn man es dann noch richtig gut machen will, verwendet man noch eine CRC Pruefsumme fuer jedes Datentelegramm und ein ACK wenn die Daten einwandfrei angekommen sind und ein NAK wenn die Pruefsumme nicht stimmt, was dann den Master dazu veranlassen sollte, das Telegramm nochmals zu senden.
Das ist jetzt nur ein schnelles Beispiel, wie man das machen koennte, ohne den Anspruch irgendwie vollstaendig zu sein.
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
Zitat von dr iv im Beitrag #12 Ich habe ja auch noch einen Nahgüterbereich, der per Hand ohne Computer steuerbar sein soll. Ich möchte aber einen Anschluss in die Welt des Digiitalen haben, um nicht mal in einer Sackgasse zu landen. Nun wollte ich wie Du eben keinen Rechner und keine Zentrale zum Schalten für den Handbetrieb verwenden. Andererseits möchte ich auch keine vielen Leitungen zum Steuern von Weichen und Signalen zwischen den Modulen haben. Da soll ein Bus mit seinem einem Kabel (Störsicherheit) existieren und so einen modularen Anschluss der Komponenten ermöglichen.
Aber unabhängig vom Konzept wird es ähnlichen Aufgabenstellungen und Lösungen geben, wo man voneinander lernen und sich austauschen kann.
Ich habe hier schon mal mit dem LocoNet rumgespielt. Und die Spielerrei war sehr erfolgreich. Seitdem steht für mich fest, dass es eine Lösung auf dieser Basis werden wird.
Was braucht man?
- Eine Konstantstromquelle, die man selber bauen kann oder man nimmt etwas fertiges z.B. von Blücher.
- Einen Master, der mindestens ein Power On auslöst, wenn der Strom eingeschaltet wird, so dass sich die Komponeten über ihren Status zu Beginn des Betriebs austauschen.
- Einen Tasten-Modul, der Schalterstellungen in LocoNet-Statusänderungs-Nachrichten umzuwandeln.
- Servo- und Lichtsignal-Module die Statusänderungs-Nachrichten in Stellebefehle umwandeln. Die Module können auch Statusmeldungen absenden, um z.B. den Stand einer Weiche zu melden.
Alle Module sollen über CVs konfigurierbar sein. Ob z.B. die Servo- und Lichtsignal-Module die Statusänderungs-Nachrichten der Tasten-Moduele direkt ausführen oder über einen Master interpretiert werden, ist noch zu klären. Wenn Fahrstassen gesteuert werden sollen, wird dies umungänglich sein. Also sehe ich hier auch verschiedene Ausbauvarianten.
Für ein Treffen kann nun ein Loconet aufgebaut werden, wass aber dann konkreten Abstimmungsaufwand erfordert. Es kann aber auch jede Betriebsstele ihr eigenes LocoNet betreiben. Beleibige Kombinationen sind denkbar. Z.B. kann ein Bahnhof einen Abzweig mit steuern.
Wie möchte ich gern weitermachen? Mit einem vorhanden Sniffer mal schauen, was so eine Z21 auf dem LocoNet ausgibt, ein lokales LocoNetin Betrieb nehmen und einen Tasten.Modul aufbauen und programmieren. Hohe Priorität hat auch ein Servo-Modul.
Soweit nun meine Vorstellungen etwas konkretisiert.
wenn es fuer Loconet die Libs fertig gibt, halte ich das auch fuer die sinnvollere Alternative. Da hat man doch gleich alles beisammen. Und elektrisch ist Loconet nicht schlechter als RS485 und ein vorhandener Standard fuer die Steuerung von Modellbahnen. Fein!
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
Hallo, eine LocoNet Lib für den Arduino gibt es hier. Die kann man aiuch direkt über den Bibliotheksverwalter installieren. Allerdings hat sie einen Nachteil: Sie verwendet den Timer 1 auf dem UNO/Nano. Der wird aber auch z.B. von der ServoLib oder meinen MobaTools verwendet. Servo-Ansteuerung ist dann also etwas problematisch. Alternative ist ein Arduino, der mehr 16-Bit Timer hat. Also Leonardo, Micro oder Mega. Auf dem Mega 'verzieht' sich die LocoNet Lib automatisch auf den Timer 5. Auf Leonardo und Micro ( und Mega ) nutzen meine MobaTools automatisch den Timer 3. Da gibt es dann keine Konflikte. Wie das bei Leonardo/Micro mit der Kompatibilität zur Standard-ServoLib ist weis ich nciht - könnte da auch noch ein Problem sein, wenn sich keiner freiwillig auf Timer 3 verschiebt.
Edit: RS485 auf dem UNO/Nano hat auch den Nachteil, dass die nur eine HW-serielle Schnittstelle haben - und die ist von der USB-Verbindung zum PC ( Programmupload und Debugging ) belegt. Da muss man das softwaremäßig realiseren.
ich hatte ein Layout für einen Servodekoder gemacht und wollte dies bestellen und habe gerade noch gemerkt, dass der Prozessor es wegen der Timer ungeeignet ist. Da ist wohl noch etwas testen angesagt.
Für Schalteranwendungen werde ich wohl die OnButton-Bibliothek verwenden, da ich zumEinstellen der CVs von Dekodern auch die Länge des Drückes brauche. Für das Servo werde ich wohl Deine Bibliothek verwenden. Hast Du da schon was für Flügelsignale angedacht?
Hatte den Beitrag zum Anlass genomme etwas zu testen und hatte dabei auch mit dem Zucken meines Servos zu kämpfen. Habe dann etwas gesucht und dabe den Vorschlag gefunden zwischen Plus und der Datenleitung einen 4,7 kOhm Widerstand vorzusehen. Seitdem verhält es sich ruhig. In Deinem Schalungsentwurf ist ja da etwas dazu enthalten, was ich in meinem Entwurf übernommen hatte.
@all Micha möchte die Leute an die Thematik des Arduinos an einem konkreten Beispiel heranführen, was ich sehr gut finde. Ich hatte meine Meinung zu seinem Projekt gechrieben und auch aufgezeigt, was ich möchte. Ich möchte aber nicht in seinem Beitrag über meine Lösung diskutieren.
Zitat von dr iv im Beitrag #32...Ich möchte aber nicht in seinem Beitrag über meine Lösung diskutieren.
ja das ist sicher fair. Hast Du schon einen eigenen Thread indem das diskutiert werden kann?
================================================= Hallo Micha, das hier ist/wird auf jeden Fall ein toller Beitrag um auch andere an das Thema Arduino heranzuführen. Man kann mit dem kleinen Ding ja so unglaublich viel in unserem Umfeld machen. Mit der gleichen Idee hatte ich auch damals angefangen, die Library 'MobaTools' zu entwickeln. Damit gehen viele Dinge doch wesentlich einfacher, und es erleichtert dementsprechend den Einstieg. Ich habe mir erlaubt, deinen Sketch aus #2 auf die MobaTools umzuschreiben - er wird da doch gleich deutlich einfacher und kürzer:
// für den Servo const byte Weiche_Gerade = 60; // Endlage des Servos wenn Weiche auf Gerade const byte Weiche_Mitte = 90; // Mittellage const byte Weiche_Abzweig = 120; // Endlage des Servos wenn Weiche auf Abzweig byte Weiche_soll = Weiche_Gerade; // Speichervariable für die aktuelle Lage const byte Stellzeit_Servo_Weiche = 10; // Stellgeschwindigkeit Weiche const byte Pin_Servo = 3; // Servo an PIN 3
// für den Taster const byte Pin_Taster = 12; // Taster an PIN 4 const byte entprellzeit = 20; // Zeitintervall der Tasterabfrage boolean taster_gedrueckt = 0; // Speichervariable für den Tasterzustand boolean last_tasterzustand = 0; // zur Erkennung der Flanke MoToTimer Entprellen; // Timer-Objekt zum Entprellen
// Anlegen eines Servo-Objektes MoToServo servo;
void setup() { // Definition des Taster PINS pinMode(Pin_Taster, INPUT_PULLUP); // wird nur 1x im Setup gemacht // INPUT_PULLUP spart den externen Widerstand ( Taster muss dann gegen Gnd schalten )
// Initialisieren der Weiche auf Grundstellung servo.attach(Pin_Servo, true); // Aktivierung ServoPin - mit automatischer Abschaltung servo.setSpeed( Stellzeit_Servo_Weiche ); // Servogeschwindigkeit einstellen servo.write(Weiche_Mitte); // Servo fährt in Mittelstellung delay(500); // Warten das der Servo die Stellung erreicht hat
// Servo fährt in Stellgeschwindigkeit in die Grundlage (in der Regel Gerade servo.write(Weiche_Gerade); }
void loop() { // Entprellen des Tasters if ( !Entprellen.running() ) { // Der Eingang wird nur alle 'entprellzeit' ms eingelesen Entprellen.setTime( entprellzeit ); // Entprellzeit neu setzen taster_gedrueckt = ! digitalRead( Pin_Taster ); // invertiert mit ! wegen INPUT_PULLUP // ( Taster schaltet gegen Gnd ) if ( taster_gedrueckt == 0 ) last_tasterzustand = 0; // Zur Flankenerkennung 'gedrückt' }
// Servobewegung wird im Moment des Tasterdrückens gestartet if ( taster_gedrueckt == 1 && last_tasterzustand == 0 ) { last_tasterzustand = taster_gedrueckt; // zur Flankenerkennung
// Abfrage der Weichenlage, Servo fährt dann in die jeweils Andere Position if ( Weiche_soll == Weiche_Abzweig ) { // Weichensollzustand umschalten Weiche_soll = Weiche_Gerade; } else { Weiche_soll = Weiche_Abzweig; } servo.write(Weiche_soll); // Servo auf neue Position fahren. }
}
Auch das Schalten des Polarisationsrelais ließe sich recht einfach so einbringen, dass es genau in der Mitte des Stellwegs umschaltet.
Ich habe noch ein paar Kleinigkeiten geändert, an die man sich meiner Meinung nach von Anfang an gewöhnen sollte: - Werte, die sich im Programm nicht ändern sollten mit const gekennzeichnet werden. Damit kann der Compiler besser optimieren, und er meldet auch einen Fehler, falls man den Wert versehentlich doch zu ändern versucht. - Werte, die nie größer als 255 werden können, sollte man als byte definieren, dass spart wertvolles RAM ( da haben die kleinen Arduinos nicht so viel von - bei umfangreichen Sketchen wird das schneller voll als man denkt ) - Man spart sich den externen Widerstand am Tasterinput, wenn man den Taster gegen Gnd schalten lässt. Das ist eigentlich Standard ( auch wenn das in den Tutorials nicht so gemacht wird ). - Die Namensgebung der Variablen und Objekte ist Geschmacksache, wobei sich da auch ein paar 'Standards' herausgebildet haben. Aber da habe ich nichts geändert. Ist ja Geschmacksache
Ich hoffe, das kommt jetzt nicht als 'Besserwisserei' rüber, und wenn Du bei deiner Variante bleiben willst - kein Problem. Musst Du nur sagen, dann lösche ich meinen Beitrag wieder.
Zitat von MicroBahner im Beitrag #33 - Werte, die sich im Programm nicht ändern sollten mit const gekennzeichnet werden. Damit kann der Compiler besser optimieren, und er meldet auch einen Fehler, falls man den Wert versehentlich doch zu ändern versucht. - Werte, die nie größer als 255 werden können, sollte man als byte definieren, dass spart wertvolles RAM ( da haben die kleinen Arduinos nicht so viel von - bei umfangreichen Sketchen wird das schneller voll als man denkt )
Der gcc kennt von Haus aus keine Harvard Architektur und legt auch const deklarierte Variaben ins RAM. Da es sich hier um Festwerte handelt, kann man die entweder gleich mit dem Praeprozessor als #define einbinden oder deklariert die ins Flash-ROM:
const __flash byte Weiche_Gerade = 60;
oder (alt)
const byte Weiche_Gerade PROGMEM = 60;
oder
#define Weiche_Gerade = 60
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
Zitat von DL7BJ im Beitrag #34Moin Franz-Peter, Der gcc kennt von Haus aus keine Harvard Architektur und legt auch const deklarierte Variaben ins RAM.
Hallo Tom, aber nur wenn unbedingt notwendig. Wenn möglich legt er die garnicht im Ram an, sondern ersetzt die entsprechenden Stellen direkt mit der Konstante - was z.B. bei Pins eigentlich immer funktioniert. Im Prinzip so ähnlich wie mit #define, - nur mit allen Compilerprüfungen. '#define' sollte man für den Zweck eigentlich nicht mehr einsetzen.
Zitat von MicroBahner im Beitrag #35 aber nur wenn unbedingt notwendig. Wenn möglich legt er die garnicht im Ram an, sondern ersetzt die entsprechenden Stellen direkt mit der Konstante. - was z.B. bei Pins eigentlich immer funktioniert. Im Prinzip so ähnlich wie mit #define, - nur mit allen Compilerprüfungen. '#define' sollte man für den Zweck eigentlich nicht mehr einsetzen.
Hast Du dazu Unterlagen? Denn hier steht es anders http://nongnu.org/avr-libc/user-manual/pgmspace.html Unter anderem wird dort auch auf const eingegangen. Das ist zwar eine Konstante, die liegt aber dann trotzdem im RAM, wenn der Compiler nicht angewiesen wird, diese ins ROM zu packen.
Gruss Tom
Ep. III DB 2L DCC WebsiteMastodon It's boring when it works!
erstmal Danke für die bisherige Diskussion. Keine Sorge, es war durchaus meine Absicht, dass es dazu kommt, auch freue ich mich über andere Herangehensweisen.(@ Franz-Peter).
Ihr sprecht Punkte an, die ich dann gern unter #5 zusammenfassen möchte.
Zunächst werde ich noch die #2-4 füllen, was allerdings noch etwas dauert, da ich das Ganze noch aufbereiten muss.
Große Klasse der Sketch, ich bin ganz ehrlich, ich bin eifriger Leser und Nutzer, zusammenhänge verstehe ich schon ganz gut und es gelingt mir auch, Anpassungen für meine Zwecke vorzunehmen, allerdings werde ich in die Tiefen des Programmierens wohl nicht mehr einsteigen. Deswegen bin ich um so dankbarer, dass es Leute gibt, die ihre tollen Projekte bereitwillig zur Verfügung stellen! Was mir in dem Sketch fehlt, ist die Rückmeldung (rote / grüne LED) kann man das noch irgendwie anfügen!
Ich wünsche frohe Feiertage, und nochmals vielen Dank, für die vielen tollen Sketche!
Für mich ist der Arduino ein Mittel zum Zweck, habe schon einige schöne Effekte für die Modellbahn damit umsetzen können!
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Analoge Technik und Fahrzeugtechnik
»
Weichensteuerung mit Arduino - Update 27.12.20 - Fahrwegausleuchtung mit LED
Thema drucken
21.01.2020 14:51 (zuletzt bearbeitet: 21.01.2020 15:00)
Antworten
