[MicroBahner]

Zitat

---

die schreibst dass deine Loconet Decoder mit dem Nano nicht laufen, wegen des Timers. Liegt das jetzt nur an den Moba Tools?

---

Hallo Ulrich,
ja, das liegt an der Kombination MobaTools <-> Loconet-Lib. Beide benötigen einen 16-Bit Timer, und der AtMega328 hat nunmal nur einen.
Auf einem UNO/Nano wollen deshalb beide den Timer 1 benutzen und kommen sich da also in die Quere.

Auf einem Mega benutzt die LocoNet Lib automatisch den Timer 5, auf UNO/Nano und Leonardo/Micro den Timer 1.
Die MobaTools benutzten immer dann den Timer 3, wenn er existiert, also auf Leonardo/Micro und auf dem Mega.
Dadurch gehen sich die beiden Libs auf Mega und Leonardo/Micro elegant aus dem Weg - Auf UNO/Nano kollidieren sie.

LocoNet ohne MobaTools und MobaTools ohne LocoNet funktionieren auch auf einem UNO/Nano. Da die nmraDCC-Lib keinen TImer benötigt, funktioniert es da auch auf einem UNO/Nano zusammen mit den MobaTools.

[Kriwatsch]

Hallo
Ich habe das bisher so verstanden, dass der Decoder in der hier vorgestellten Konfiguration mit dem AT328P einen zweiten unabhängigen Timer benötigt, für Loconet Baust Du das Ganze mit einem Mega auf dann hast Du mehr als einen Timer. Daraus folgt für mich, mit UNO,NANO nur entweder - oder, weil die nur einen Timer haben.
Ciao
Micha

[MicroBahner]

Hallo Micha,
ja so ist das. Aber auch der ATmega32u4 auf Leonardo/Micro hat schon 2 16-Bit Timer ( Timer1 und TImer3 ). Deshalb braucht es nicht unbedingt einen Mega. Und der proMicro ist genauso kompakt wie der Nano und nur wenig teurer.

[Kriwatsch]

Hallo Franz-Peter
Der Mega war als Beispiel genannt. Wichtig ist ein zweiter unabhängiger Timer Welchen man dann nimmt - eigener Gusto! Habe aus China wieder was bekommen
Ciao
Micha

[Murdock412]

Hallo,

nach längerer Abwesenheit durch Urlaub und Wetter melde ich mich dann auch mal wieder. Mittlerweile habe ich meine Eigenbau-Arduinos einwandfrei zum laufen bekommen und steuere mit jedem davon 8 Servos über die z21 per Tablet. Die vormals aufgetauchten Probleme mit Cv`s, die sich verselbstständigen oder allgemeinen Problemen, die zu totaler Funktionslosigkeit führten, haben sich mittlerweile erledigt.

Allerdings taucht jetzt doch ein neues, interessantes Problem auf, zu dem ich hier noch nichts weiter gefunden habe. Sobald ich mehrere meiner Decoder in meine Steuerung einbinde ( jeder mit eigenem "DCC auf Arduino"-Adapter ), stellt irgendein anderer Decoder seine Funktion ein. Tausche ich die ankommende DCC-Spannung, funktionieren entweder beide oder gar keiner. Problematisch wird dieses Phänomen mit steigender Anzahl Decoder ( drei hab ich momentan gleichzeitig aktiv), da dann das hin- und Hertauschen der DCC-Spannung bis alles funktioniert sehr aufwändig und nervig wird. Auch steuern die Decoder jetzt teilweise nicht mehr mehrere Servos gleichzeitig, wenn dies per Fahrstrasse in der App angefordert wird. Ist nur ein Decoder angeschlossen, klappts einwandfrei.

Da im Einzelbetrieb soweit alles klappt, sollte es nicht an den Platinen liegen. Versorgt werden die Arduinos über die 5 Volt eines PC-Netzteils, die DCC-Spannung der z21 liegt bei ca. 17 Volt aus dem Standard-Netzteil, dass der z21 beilag.

Damit dann zu meiner Frage: Hat jemand das gleiche Problem (gehabt) und weiß Rat?

[black5]

Moin,

Zitat

---

Tausche ich die ankommende DCC-Spannung, .... da dann das hin- und Hertauschen der DCC-Spannung...

Versorgt werden die Arduinos über die 5 Volt eines PC-Netzteils, die DCC-Spannung der z21 liegt bei ca. 17 Volt aus dem Standard-Netzteil, dass der z21 beilag.

---

Was bitte verstehst du unter "Tausche ich die ankommende DCC-Spannung"? Tauschst du da die rechte Klemme/Schiene mit der linken Klemme/Schiene ? Oder wie muss ich mir das vorstellen.

Und haben deine Netzteile alle die Masseanschlüsse miteinander verbunden (gemeinsame Masse). Und wie sieht es aus mit dem Netzteil für die Servos? Wo kriegen die ihre Versorgungsspannung her und hast du da auch an die gemeinsame Masse gedacht?

So viele Fragen am Sonntag Morgen

Ulrich

[fbstr]

Zitat

---

Da im Einzelbetrieb soweit alles klappt, sollte es nicht an den Platinen liegen. Versorgt werden die Arduinos über die 5 Volt eines PC-Netzteils, die DCC-Spannung der z21 liegt bei ca. 17 Volt aus dem Standard-Netzteil, dass der z21 beilag.

---

Moin,
ich bin jetzt absolut nicht der Arduino-Experte, aber beim Arduino Nano wird als Spannungsversorgung 7-12V angegeben.
Deshalb habe ich bei mir eine 5V Spannungsversorgung für die Servos und 9V Spannungsversorgung für den Arduino.

Könnte es daran liegen dass Deine 5V nicht ausreichen?

[Siki]

Es ist korrekt das die Arduino's einen Spannungsregler haben und dieser mit min. 7V versorgt werden sollte, da der Regler immer ein bisschen Spannung vernichtet. Allerdings gibt es für den fall das man schon saubere 5V hat auch den "RAW" Eingang, dieser umgeht den Spannungsregler, aber dann muss die Spannung stabil sein...
Im falle des Arduino Nano's ist der RAW Pin gleich dem 5V Pin, man kann diesen nutzen, aber wenn die Spannung mal über 5V geht ist der Arduino am Ende...

Lg Simon

[Murdock412]

Tach, danke schonmal für die vielen Antworten und Ideen. Ich versuche mal die grundlegenden Fragen zu beantworten.

Zitat

---

Was bitte verstehst du unter "Tausche ich die ankommende DCC-Spannung"? Tauschst du da die rechte Klemme/Schiene mit der linken Klemme/Schiene ? Oder wie muss ich mir das vorstellen.

---

Ja, genau so ists im Prinzip gemeint. Ich habe eine Hauptverteilerleiste, von dieser wird alles versorgt.

Zitat

---

Und haben deine Netzteile alle die Masseanschlüsse miteinander verbunden (gemeinsame Masse). Und wie sieht es aus mit dem Netzteil für die Servos? Wo kriegen die ihre Versorgungsspannung her und hast du da auch an die gemeinsame Masse gedacht?

---

Ich habe eine DCC-Spannung (z21) und eine 5 volt Spannungsversorgung, die jeweils den dazu gehörenden bereich versorgen. Diese beiden Spannungen sind logischerweise voneinander getrennt. Auf der 5 Volt-Ebene hat dementsprechend alles eine gemeinsame Masse.

Zitat

---

Könnte es daran liegen dass Deine 5V nicht ausreichen?

---

die 5 Volt greife ich mir an meinem Desktop-PC-Netzteil ab, die sollten relativ stabil und leistungsstark sein.
Verbaut habe ich wie schon erwähnt Eigenbaudecoder, basierend auf dem Atmel 328p. Diese sollen lt. Datenblatt mit 5Volt betrieben werden. Davon hatte ich vorher insgesamt 10 Stück als Steuerung für Servos, Relais und LEDs in Betrieb, allerdings klassisch mit Schaltern und Reed-Kontakten angesteuert. Dies hat auch einwandfrei funktioniert. Wenn ich raus gefunden habe, wie ich Bilder direkt vom Rechner einfüge, kann ich gerne die entsprechende Hardware zeigen.

[MoBa_Alfred]

Hallo Simon,

Zitat

---

..... Allerdings gibt es für den fall das man schon saubere 5V hat auch den "RAW" Eingang, dieser umgeht den Spannungsregler, aber dann muss die Spannung stabil sein...
Im falle des Arduino Nano's ist der RAW Pin gleich dem 5V Pin....

---

Damit bin ich nicht ganz einverstanden.
Der RAW Eingang ist bei den Arduinos immer der Eingang für "ungeregelte" Spannung (ca.7-20V) und geht über den Spannungsregler.
Der RAW Pin ist bei vielen Arduinos auch als "VIN" bezeichnet.
Sicher geregelte 5V kann man in die +5V oder VCC Pins einspeisen.

Quelle: Arduino Schematics und arduino.cc

Grüße
Alfred

[black5]

Ich würde die Nanos nach Möglichkeit über Vin mit Spannung versorgen, nach Möglichkeit 7 bis 9 Volt. Versorgt man sie über den 5 Volt Pin besteht die Gefahr daß bei einer zu hohen Spannung (+10%) der atmega hochgeht, ebenso besteht die Gefahr wenn ich den USB Anschluss einstecke zum Programmieren das entweder der PC/Laptop einen mitkriegt oder der 5 Volt Regler auf dem nano.
Bei der 3,3 Volt Variante können 4 Volt den Tod des Nanos bedeuten.
@Murdock
Wie steuerst du die Servos an, direkt mit den digital Pins?
Und wieso ändert sich das DCC verhalten wenn du die Anschlüsse tauschst - DCC sollte ein symetrisches Rechtecksignal sein - ausser du hast viele extended Zero Signale, weil bei dir irgendetwas analoges angesteuert wird.
Ulrich

[MicroBahner]

Zitat

---

Und wieso ändert sich das DCC verhalten wenn du die Anschlüsse tauschst - DCC sollte ein symetrisches Rechtecksignal sein

---

Ich denke auch, dass man hier ansetzen müsste. Da stimmt etwas nicht. Das Verhalten darf nicht davon abhängen, mit welcher Polarität das DCC-Signal angeschlossen ist.

[Murdock412]

Hi,

ich mal wieder. So wie es scheint, habe ich die Lösung gefunden. Die 5 Volt aus meinem Tower-PC-Netzteil waren wohl nicht die saubersten, obwohl messtechnisch dauerhaft 5,122V anstanden. Nur beim Schalten der Servos brach die ab und zu auf 5,064V ein. ich habe jetzt einfach mal zwei 1000µF-Kondensatoren in auf die Einspeisung geklemmt und siehe da: Alles läuft wie gedacht.

[211064]

Hallo Franz-Peter, hallo DIY-Zubehördecoder-Community,

zunächst: Danke dir, Franz-Peter, für die ganze Arbeit, die Du in diesen DIY-Decoder steckst! rost: Und allen anderen, die hier kommentiert haben auch - ich habe viel gelernt. Aber wohl nicht genug, denn ich kriege den Decoder nicht ans Laufen.

***Hat sich erledigt, sorry. Ich hätte früher schlafen gehen sollen ops: . Aber wer den eigentlichen Sketch nicht hochlädt, der kann den Decoder nicht ans Laufen kriegen. ***

[volkerS]

Hallo Christoph,
du hast hoffentlich den Leds einen Vorwiderstand spendiert. Sonst ist möglicherweise A0 und A3 zerstört und noch mehr.
Volker

[211064]

Guten Morgen,

@Volker: Ja, habe ich. Aber das war ja nicht das Problem ...

[211064]

Hallo Franz-Peter, hallo DIY-Zubehördecoder-Community,

im zweiten Anlauf - mit *.ino-Datei - leuchtet beim Start des Decoders die LED an A0. ABER: Ich kann genau einmal schalten. Sprich: Wenn ich mit der Lokmaus2 einen Schaltbefehl gebe, wechselt der Decoder von A0 auf A1. Die LED an A0 blendet ab, die an A1 blendet auf. Aber ich kann nicht wieder zurück auf die LED an A0 schalten. Erst mit RESET am Board leuchtet die LED an A0 wieder und das Spiel kann von vorne beginnen. Es ist zum Mäusemelken! Jeder weitere Weichenbefehl aus der Lokmaus bewirkt nichts. Das gleiche Verhalten zeigt sich auch an A3/A4, also mit der nächsten Adresse.

Bodo hat vorgesehen, in der DCC-Zubehoerdecoder.h-Datei

1
 

#define FIXMODE INIMOD
 

zu setzen, damit A5 bzw. beim LS-Decoder A7 frei bleiben können. Das habe ich gemacht. Ich habe es auch mit NORMALMODE versucht - das bringt keine Änderung. Tja, jetzt stehe ich wie der Ochs vor'm Berg und weiß nicht weiter. Kann mir bitte jemand auf die Sprünge helfen?!

Der Code meiner DCC-Zubehoerdecoder.h:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
 

 
/* Universeller DCC - Zubehördecoder
 **************************************************************************************************
 * Beispieldatei für  L i c h t h a u p t s i g n a l e (ohne Vorsignale am gleichen Mast).  
Fürs Forum habe ich den Kommentar weggelassen
  */
#define ENCODER_DOUBLE  // Eigenschaften des Drehencoders (Impulse per Raststellung)
 

// vom Anwender änderbare Parameter um den Zubehördecoder an die verwendete HW anzupassen
 
// Beispiel für Variante mit Licht-Ausfahrsignal mit Vorsignal, mit Betriebsmode Led an Pin 13 (interne Led)
 
//----------------------------------------------------------------
// Hardwareabhängige Konstante ( nicht per CV änderbar)
//----------------------------------------------------------------
const byte dccPin       =   2;
const byte ackPin       =  NC;
 
// Eingänge analog: ( Bei Nano und Mini - Versionen kann hier auch A7 und A6 verwendet werden, um mehr
//                    digital nutzbare Ports freizubekommen.
//                    beim UNO sind A7+A6 nicht vorhanden! )
#define FIXMODE NORMALMODE    
const byte betrModeP    =   A7;     // Analogeingang zur Bestimmung des Betriebsmodus. Wird nur beim
                                    // Programmstart eingelesen!
const byte resModeP     =   A6;     // Rücksetzen CV-Werte + Mittelstellung Servos
 
// Eingänge digital (die Ports A0-A5 lassen sich auch digital verwenden): ---------
 
// Drehencoder zur Servojustierung ...........
//#define ENCODER_AKTIV       // Wird diese Zeile auskommentiert, wird der Encoder nicht verwendet. 
                            // Die Encoder-Ports werden dann ignoriert, und können anderweitig 
                            // verwendet werden.
const byte encode1P     =   NC;     // Eingang Drehencoder zur Justierung.
const byte encode2P     =   NC;
// ............................................
//-------------------------------------------------------------------------------------------------------
// Betriebswerte ( per CV änderbar ) Diese Daten werden nur im Initiierungsmodus in die CV's geschrieben.
// Der Initiierungsmodus lässt sich per Mode-Eingang aktivieren oder er ist automatisch aktiv, wenn keine
// sinnvollen Werte im CV47 stehen.
//-------------------------------------------------------------------------------------------------------
const byte DccAddr          =  17;    // DCC-Decoderadresse
const byte iniMode          = 0x50 | AUTOADDR | ROCOADDR ;  // default-Betriebsmodus ( CV47 )
const int  PomAddr          = 50;    // Adresse für die Pom-Programmierung ( CV48/49 )
 

//Konstante für Lichtsignalfunktion
#define SIG_DARK_TIME   300     // Zeit zwischen Dunkelschalten und Aufblenden des neuen Signalbilds
#define SIG_RISETIME    500     // Auf/Abblendezeit
 
// Ausgänge:  mit NC gekennzeichnete Ausgänge werden keinem Port zugeordnet. Damit können Ports gespart werden,
//            z.B. wenn bei einem Servo kein Polarisierungsrelais benötigt wird
const byte modePin      =   13;     // Anzeige Betriebszustand (Normal/Programmierung) (Led)
 
#define MAX_LEDS 16 // default ist 16. Kann auf die tatsächlich benutzte Zahl reduziert werden, um RAM zu sparen.
                    // Pro Softled werden 19 Byte benötigt
                   
const byte iniTyp[]     =   { FSIGNAL2, FSIGNAL0, FSIGNAL2, FSIGNAL0, FSIGNAL2, FSIGNAL0, FSIGNAL2, FSIGNAL0,  FSIGNAL2, FSIGNAL0  };
const byte out1Pins[]   =   {       A0,       NC,       A3,       NC,        3,       NC,        6,       NC,         9,       NC  }; 
const byte out2Pins[]   =   {       A1,       NC,       A4,       NC,       13,       NC,        7,       NC,        10,       NC  };
const byte out3Pins[]   =   {       A2,       NC,       A5,       NC,        5,       NC,        8,       NC,        11,       NC  };
                                                                                                                                  
const byte iniFmode[]     = {        0, 0b000100,        0, 0b000100,        0, 0b000100,        0, 0b000100,         0, 0b000100  };
const byte iniPar1[]      = { 0b001001, 0b110001, 0b001001, 0b110001, 0b001001, 0b110001, 0b001001, 0b110001,  0b001001, 0b110001  };
const byte iniPar2[]      = { 0b100010, 0b100110, 0b100010, 0b100110, 0b100010, 0b100110, 0b100010, 0b100110,  0b100010, 0b100110  };
const byte iniPar3[]      = {        0,        0,        0,        0,        0,        0,        0,        0,         0,        0  };
const byte iniPar4[]      = { 0b000101,        0, 0b000101,        0, 0b000101,        0, 0b000101,        0,  0b000101,        0  }; 
//------------------------------------------------------------------------------------
 
 

[Bodo]

Hallo Christoph,

Zitat

---

Bodo hat vorgesehen, in der DCC-Zubehoerdecoder.h-Datei

1
 

#define FIXMODE INIMOD
 

zu setzen, damit A5 bzw. beim LS-Decoder A7 frei bleiben können. Das habe ich gemacht. Ich habe es auch mit NORMALMODE versucht - das bringt keine Änderung. Tja, jetzt stehe ich wie der Ochs vor'm Berg und weiß nicht weiter. Kann mir bitte jemand auf die Sprünge helfen?!

---

... ist vermutlich nur ein Kopierfehler, da fehlt ein E:

1
 

#define FIXMODE INIMODE
 

Meiner Meinung nach sollte der Dekoder (ohne Programmierung) erstmal so betrieben werden, um auszuschließen, dass er falsche Werte aus dem EEPROM verwendet.

Außerdem macht die Belegung so nur begrenzt Sinn - wenn Du nur ein zweibegriffiges Signal verwendest, solltest Du auch nur "FSIGNAL2" verwenden - denn wenn Du in Deinem Beispiel mit Adresse 17 anfängst, wäre die nächste (für A3 und A4) bei Dir 19 (weil 18 die zweite Adresse des ersten Signals ist.

Versuche es doch mal (keep it simple) mit
[Code]
#define FIXMODE INIMODE
const byte iniTyp[] = { FSIGNAL2, FSIGNAL2 };
const byte out1Pins[] = { A0, A3 };
const byte out2Pins[] = { A1, A4 };
const byte out3Pins[] = { NC, NC };
const byte iniFmode[] = { 0, 0 };
const byte iniPar1[] = { 0b001, 0b001 };
const byte iniPar2[] = { 0b110, 0b110 };
const byte iniPar3[] = { 0, 0 };
const byte iniPar4[] = { 0, 0 };
//------------------------------------------------------------------------------------
[/code]

Viele Grüße, Bodo

[211064]

Hallo Bodo,

danke für deinen Beitrag. Das fehlende "E" war (leider) nur ein Kopierfehler hier im Forum. In der h-Datei steht korrekt "INIMODE". Ich werde die Software noch einmal "frisch machen", also die bisher verwendeten DCC-Zubehoerdecoder-Dateien löschen und die zip-Archive von Decoder und Bibliotheken neu entpacken. Vielleicht hat sich irgendwo ein Fehler eingeschlichen.
Die LEDs dienen nur dem Test. Wenn ich mit dem Decoder klarkomme, soll er zwei zweibegriffige und ein dreibegriffiges Signal ansteuern.

[211064]

Tach zusammen,

gestern hatte ich die Muße, mir den Decoder noch einmal vorzuknöpfen. Alles noch einmal auf Anfang, also die Decoder-Software und die Bibliotheken noch einmal frisch heruntergeladen und in eine frische Arduino-IDE-Installation eingebracht - jetzt funktioniert es!

Damit stehe ich vor der nächsten Frage. Ich möchte an den Decoder 3 2-begriffige Signale mit gemeinsamem Pluspol direkt anschließen. Damit das funktioniert, muss ich Bit7 in der Zeile const byte iniFmode auf 1 setzen, richtig? Leider weiß ich nicht, wie das geht ... ops: In Bodos Beispiel, (das ich um eine Spalte FSIGNAL2 ergänzen werde) steht in der Zeile const byte iniFmode eine 0. Da es sich um Bit7 handelt, glaube ich kaum, dass ich dort nur eine 1 reinschreiben muss. Aber was dann? Vielleicht so wie in der Beispieldatei in der gleichen Zeile, Spalte FSIGNAL0 und dort an 7. Stelle eine 1? Also so:

1
2
3
4
5
6
7
8
9
10
11
12
 

#define FIXMODE INIMODE
const byte iniTyp[]     =   { FSIGNAL2, FSIGNAL2 };
const byte out1Pins[]   =   {       A0,       A3 }; 
const byte out2Pins[]   =   {       A1,       A4 };
const byte out3Pins[]   =   {       NC,       NC };                                                                 
const byte iniFmode[]  = {0b000110,   0b000110 };
const byte iniPar1[]      = {    0b001,    0b001 };
const byte iniPar2[]      = {    0b110,    0b110 };
const byte iniPar3[]      = {        0,        0 };
const byte iniPar4[]      = {        0,        0 };
//------------------------------------------------------------------------------------
 
 

Was bedeutet das "b" in diesen 0/1-Reihen?

[MicroBahner]

Hallo Christoph,

Zitat

---

Was bedeutet das "b" in diesen 0/1-Reihen?

---

das 'b' bedeutet, das diese Zahl in Binärschreibweise angegeben ist. Also jede Stelle hinter dem b entspricht einem Bit. Für ein Byte sind das also bis zu 8 Stellen.

1
2
3
4
5
6
7
8
9
10
 

0b00000000
  |    ||^-Wert für Bit 0
  |    |^--Wert für Bit 1
  |    ^---Wert für Bit 2
  |       ...      
  ^---------Wert für Bit 7
  
z.B. nur Bit 7 gesetzt:
0b10000000
 

Da führende Nullen nicht geschrieben werden müssen, können da auch weniger als 8 Stellen stehen, wenn die höherwertigen Bits '0' sind.
Das erleichtert die Schreibweise, wenn es eigentlich nicht um den Zahlenwert des Byte geht (0...255), sondern jedes Bit eine individuelle Bedeutung hat. Dann muss man nicht in Dezimal umrechnen. Wenn Du statt des binären '0b10000000' dezimal '128' schreiben würdest, wäre es dasselbe.

[211064]

Hallo Franz-Peter,

vielen Dank für die Erklärung. Wieder etwas gelernt . Ich habe 0b1 eingetragen, jetzt kann ich das Signal direkt ansteuern. Allerdings geht es beim Start des Decoders nicht auf HP0 (es handelt sich um ein zweibegriffiges Einfahrsignal), sondern auf HP1. Um das zu vermeiden, kann ich die signalseitigen Anschlusskabel vertauschen - oder ich tausche die Werte von iniPar1 und iniPar2, verstehe ich das richtig?
Das ist für das 2-begriffige Einfahrsignal nicht entscheidend, aber demnächst kommt noch ein dreibegriffiges dazu, da müsste ich ja die beiden Werte ebenfalls vertauschen, wenn ich das richtig verstanden habe.

[MicroBahner]

Hallo Christoph,

Zitat

---

Ich habe 0b1 eingetragen,

---

Wo hast Du dies eingetragen? 0b1 bedeutet, dass Bit 0 gesetzt ist., Bit7...Bit1 sind 0.

Zitat

---

Um das zu vermeiden, kann ich die signalseitigen Anschlusskabel vertauschen - oder ich tausche die Werte von iniPar1 und iniPar2, verstehe ich das richtig?

---

ja, das sollte aufs Gleiche hinauslaufen. Letztendlich kommt es immer darauf an, was Du an welchem Pin angeschlossen hast, und wie Du sie dann in den Parametern konfigurierst.
Vielleicht zeigst Du mal die entsprechenden Zeilen der Konfiguration, und schreibst, welche Singal-Led an welchem Pin angeschlossen ist.

[211064]

Hallo Franz-Peter,

danke für deine Antwort zu so später Stunde.

Zitat

---

Hallo Christoph,

Zitat

---

Ich habe 0b1 eingetragen,

---

Wo hast Du dies eingetragen? 0b1 bedeutet, dass Bit 0 gesetzt ist., Bit7...Bit1 sind 0.

---

Und ich dachte, ich hätte es verstanden ...

Dein Beispiel:

Zitat

---

z.B. nur Bit 7 gesetzt:
0b10000000

---

und den Hinweis, dass man die führenden Nullen nicht schreiben muss, habe ich so verstanden, dass man Bit 7 mit 0b1 setzt. Weil die Bits von rechts nach links gezählt werden, habe ich gedacht, dass die "führenden" Nullen auch von rechts nach links gedacht sind. Offensichtlich nicht .

Meine Parameter (ich habe Bodos Vorschlag aus #443 angewendet) sehen im Moment so aus:

1
2
3
4
5
6
7
8
9
10
 

const byte iniTyp[]     =   { FSIGNAL2, FSIGNAL2, FSIGNAL2 };
const byte out1Pins[]   =   {       A0,       A2,       A3 }; // rote LED
const byte out2Pins[]   =   {       A1,       A3,       A4 }; // grüne LED
const byte out3Pins[]   =   {       NC,      NC,      NC };
                                                                                                                                  
const byte iniFmode[]     = {      0b1,      0b1,      0b1 };
const byte iniPar1[]      = {    0b001,    0b001,    0b001 };
const byte iniPar2[]      = {    0b110,    0b110,    0b110 };
const byte iniPar3[]      = {        0,        0,        0 };
const byte iniPar4[]      = {        0,        0,        0 }; 
 

Ich werde jetzt "0b10000000" in iniFmode schreiben und dann berichten, wie die Signale reagieren.

[MicroBahner]

Zitat

---

und den Hinweis, dass man die führenden Nullen nicht schreiben muss, habe ich so verstanden, dass man Bit 7 mit 0b1 setzt. Weil die Bits von rechts nach links gezählt werden, habe ich gedacht, dass die "führenden" Nullen auch von rechts nach links gedacht sind. Offensichtlich nicht .

---

Hallo Christoph,
das ist eigentlich ganz genauso wie bei Dezimalzahlen. Wenn dein Stromzähler daheim eine 8 stellige Anzeige hat, und da steht '00003600', dann hast Du 3600 kwh verbraucht. Die Nullen links sind irrelevant, und können weeggelassen werden. Wenn Du die Nullen rechts weglassen könntest würde es billig .

Aber Vorsicht bei C/C++, wenn da nur eine führende 0 steht ( ohne die Kennzeichner 'b' oder 'x' ), wird die Zahl als 'Oktalzahl' interpretiert:
0b10111 - Binärzahl (identisch mit 0b0001011)
0x17 - Hexzahl ( identisch mit 0x0017 )
027 - Oktalzahl (identisch mit 0027 )
23 - Dezimalzahl ( nicht identisch mit 023 )
alle 4 Varianten oben stellen letztendlich die gleiche Zahl dar. D.h. bei C/C++ darfst du bei Dezimalzahlen keine führenden Nullen schreiben.

Mit dem richtigen Wert bei iniFmode sollten deine Signale im Ruhezustand dann auch Hp0 anzeigen.