Jump to content

Recommended Posts

Geschrieben

Hallo,

 

ich muss für meine Anwendung das Standardverhalten der Firmware des IO16 Bricklets ändern. Statt eine Input mit Pull-Up benötige ich Low-Outputs.

 

Sehe ich es richtig, dass ich lediglich diese Zeilen

 

void constructor(void) {

...

// Default is input pull up

io_write(I2C_INTERNAL_ADDRESS_GPPU_A+i, 0xFF);

io_write(I2C_INTERNAL_ADDRESS_IODIR_A+i, 0xFF);

...

}

 

wie folgt

 

void constructor(void) {

...

// Default is input pull up

io_write(I2C_INTERNAL_ADDRESS_OLAT_A+i, 0x00);

io_write(I2C_INTERNAL_ADDRESS_IODIR_A+i, 0xFF);

...

}

 

ändern muss?

 

Hab mich leider noch nicht in die Firmware eingearbeitet, muss aber kurzfristig eine Lösung herstellen.

 

Besten Dank im voraus.

 

Cheers,

Jörg

 

Geschrieben

Wenn ich die Spannung anlege (nicht über USB, da ich WLAN nutze), fährt der Brick hoch und initialisiert die IO-Bänke. Von diesen IOs nutze ich ein paar zum Steuern von diversen Schaltungen. Bis ich mit einer Software die Bricklets neu initialisiert habe, ist es schon zu spät.

 

Im Konstruktor könnte ich auch einfach am Ende die setPortConfiguration aufrufen, aber dann ist es auch schon zu spät. D.h. so früh wie nur irgend möglich die Ports richtig initialisieren.

 

Cheers,

Jörg

Geschrieben
Bis ich mit einer Software die Bricklets neu initialisiert habe, ist es schon zu spät.

 

Das wuerde mich interessieren. Warum ist es dann zu spaet, bzw. wieso kommt Deine Schaltung nicht mit Ports klar die zunaechst auf "Input" gestellt sind.

 

Der Loetkolben

Geschrieben

Input ist wohl nicht das Problem, eher der Pull-up.

Ich habe am Port einen N-MOS hängen, der entsprechende Sachen schaltet.

Schaltung:

 

Port->  Gate-Widerstand - NMOS

                        |

              Pull-Down-Wiederstand

                        |

                        _

 

Durch Input-Pullup leitet der NMOS nach sehr kurzer Zeit und das ist unschön.

Bei Output-Low sperrt er ordnungsgemäß und bei Output-High schaltet er sauber.

 

Aber meine Frage ist damit immer noch nicht beantwortet. Muss ich es halt testen...

 

Prozess:

1. Spannung anlegen. (Tinker und einige andere Sachen erhalten Spannung)

    ---- Ab hier müssen Tinkerforge-Baugruppen einen validen Status erreichen.

2. Hauptschalter betätigen (Sämtliche andere Schaltungen sind aktiv)

3. Entfernen vom Gerät.

4. Software starten und mit Gerät verbinden

5. Gerät über WLAN nutzen

6. Hauptschalter betätigen (Sämtliche andere Schaltung sind inaktiv)

7. Spannung trennen.

Geschrieben

Natuerlich beantwortet das nicht deine Frage, aber ich kann sie leider auch nicht beantworten. Eigentlich muesstest du in der Firmware nur die Bits beim Init passend setzen und die Firmware compilieren. "Eigentlicht."  :)

 

Ich versuche dir ja nur einen Workaround anzubieten, da ich nicht weiss wo und wie das geht.  ;)

 

Durch Input-Pullup leitet der NMOS nach sehr kurzer Zeit und das ist unschön.

 

Ok, das mag unschoen sein, aber ist das schaedlich fuer die Schaltung oder fuer die Funktion einer Kompenente?

 

 

Der Loetkolben

Geschrieben

Ja, wenn man wie in meinem Fall Sachen anschließt, die nur zu einem bestimmten Zeitpunkt ausgelöst werden sollen, dann schon. (Feuerwerk-Zündanlage)

 

Zum Glück habe ich noch Hardware-Schalter eingebaut, welche die Hauptspannung erst einschalten. Randschaltungen, wie beispielsweise ein ziemlich lauter Summer (zur akustischen Warnung) sind aber direkt an die Versorgungsspannung angeschlossen. D.h. der Summer meldet sich beim Anlegen der Hauptversorgung bis zum Initialisieren. Unschönes verhalten, zumal der Summer ausgelegt ist, in einer Entfernung wahrgenommen zu werden. Wenn ich direkt am Gerät stehe und den Schalter umlege, holla die Waldfee, das klingelt in den Ohren...

 

Ich hab versucht die setPortConfiguration-Output Einstellung in den constructor zu übernehmen (wie oben ausgeführt). Mal schauen was beim nächsten Testlauf raus kommt...

 

Cheers,

Jörg

Geschrieben

 

 

... und ich habe es immer noch nicht verstanden. Sorry.

 

Was pasiert wenn der Pin erstmal auf Eingang steht? Ist das nur unschoen oder wird dadurch _wirklich_ eine Fehlfunktion ausgeloest?

 

Angenommen die Firmware wird geaendert. Was passier dann in der Zeit zwischen "Power on" und "Chip Initialisierung". Auch das sind ggf. ein paar Millisekunden. Das wuerde kein Problem darstellen?

 

 

Der Loetkolben

Geschrieben

Hallo,

 

sorry, ich war auf einem Anwendertreffen eines Softwareherstellers und konnte daher nicht antworten.

 

Nochmals zum Aufbau:

 

a) Es wird später eine oder mehrere Zündmodule geben, die entfernt voneinander stehen werden.

b) Gesteuert wird das ganze über ein Tablet in einiger Entfernung.

 

1) Ich schließen nun jeden Kanal eines Zündmoduls an die Zünder an.

2) Danach schalte ich die Spannungsversorgung ein. Hierdurch fährt TF hoch.

3) Nun lege ich den Entsperr-Schalter um, womit alle angeschlossenen Schaltungen die entsprechende Versorgungsspannung erhalten. Weiterhin wird die Hauptspeisung durch Kondensatoren unterstützt. Diese Kondensatoren werden über Widerstände aufgeladen und letztendlich bei erreichen einer Schwell-Spannung werden die Widerstände überbrückt.

4) Zündmodul (im Koffer) wird abgeschlossen.

5) Entfernen vom Gefahrenbereich

6) Verbinden mit Zündmodulen über WLAN.

7) Durchführen von Kanaltests (Widerstandsmessung jedes Kanals und Berechnung ob Zündstrom ausreicht).

8) Anlage wird schlafen gelegt.

 

... Ein paar Stunden vergehen nun ...

 

9) Anlage aufwachen lassen

10) Durchführen von Kanaltests.

11) Hauptspannung (36V) einschalten (über TF eines IO-Ports)

12) Warnton ertönen lassen. 30 Sekunden lang, gepulst

13) Optische Warnmeldung (rote blinkende LEDs)

14) Programm mit Zündreihenfolge ablaufen lassen.

15) Publikum Ooohs und Aaahs aufsagen lassen (machen die automatisch, ohne Quatsch)

16) Hauptspannung (36V) über TF ausschalten.

17) Warten auf Nachzündungen

18) Begutachten der Feuerstelle und Entsperr-Schalter ausschalten.

19) Hauptspannung ausschalten.

 

Ende

 

Bei 3 meldet sich der Summer schon und das geht leider nicht.

 

Cheers,

Jörg

 

P.S.: Da ich im 36V-Teil noch einen Fehler habe, werde ich mich erst am WE mit der Firmware-Erstellung auseinander setzen.

Geschrieben

@JoergK: Wenn du die Firmware änderst ist der Default-Zustand bis der Constructor aufgerufen wird trotzdem Input Pullup (GPIO Pinne von ICs haben fast immer Input Pullup als Default).

 

Die sicherste Lösung wäre eigentlich wenn du einen zusätzlichen Pulldownwiderstand in deine Schaltung einbaust der stärker ist als der Pullup. Sowas wie 1kOhm oder 4.7kOhm.

Geschrieben

Hallo,

 

cool das sich jemand vom TF-Team meldet.

 

Zum einen habe ich einen Pull-Down vorgesehen, jedoch mit 47K. Ich gehe mit 1K von TF-Port zum Gate und mit 47K vom Gate zu GND. Wollte so wenig Strom wie möglich verbrauchen, aufgrund der 4 bis 5 Stunden Stand-By Zeit. Vielleicht ist in dem Fall der Pull-Down zu groß dimensioniert.

 

Jedoch wenn ich die Firmware ändere, dann habe ich wie oben im Ablauf zwischen Punkt 1 und 3 Zeit. Da TF schon mit der Versorgungsspannung versorgt wird, und die anderen Schaltungen erst mir dem Schalten des Entsperr-Schalters (Schlüsselschalter) mit Spannung versorgt werden, sollte die Firmware soweit die Ports initialisiert haben. Wenn die blauen LEDs für die Bricklet-Ports nicht mehr blinken, sollte doch alles ok sein.

 

Cheers,

Jörg

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...