Entwicklung eines Tastsensors

[mumpf]

Ich vermute, dass die ps1 skripte bei euch irgendwie aus dem "Haupt"-Ordner (z.b. SEN-UP1-8xTH) ausgeführt werden.

Alle Skripte sind relativ zu einem Projektordner, normalerweise das OAM-xxx. Das ist das "Ding", aus dem am Ende die ETS-Applikation und die Firmware rauspurzeln. Und wie Ing-Dom schon sagte, wir haben für alles Tasks definiert, immer zur Kommandozeile zu wechseln wäre viel zu umständlich im täglichem Betrieb.

Gruß, Waldemar

[mumpf]

Hmm, ja ich will den empfangenen Text anzeigen.

Du kannst einen per KO empfangenen Wert auf Deinem Display anzeigen, das hat aber nichts mit einem Parameterwert zu tun. Du solltest unbedingt vermeiden, per Firmware Parameterwerte zu ändern. Die sind statisch, werden von der ETS geschrieben und NICHT durch andere Software verändert.

Gruß, Waldemar

[cad435]

Ok, passt, ich such mir die tasks im PIO raus, Danke!

Du kannst einen per KO empfangenen Wert auf Deinem Display anzeigen, das hat aber nichts mit einem Parameterwert zu tun. Du solltest unbedingt vermeiden, per Firmware Parameterwerte zu ändern. Die sind statisch, werden von der ETS geschrieben und NICHT durch andere Software verändert.

Gruß, Waldemar

Ja wie gesagt, da hab ich mich falsch ausgedrückt. Ich wollte die Parameter auch nie über die Firmware ändern

[cad435]

Bin grad dabei mir mein Debugging-Setup zusammenzubauen:

Ich lese hier immer wieder "KNX und USB nicht gleichzeitig anschließen" --> Soweit ganz klar, KNX-GND kein fixes Potential, da verdrosselt, USB-GND aber schon.

Das heißt ich muss ja "nur" RX/TX von der BCU einmal galvanisch trennen.

image.png
(MX1 & MX2 bitte getrost ignorieren!, R15...R17 werden nicht bestückt)

Was mich nun verwirrt ist, dass ich einige Statements so interpretiere, dass selbst wenn diese Trennung da ist (idr. wird ja ein USB-Isolator empfohlen) das Setup nicht dauerhaft betrieben werden sollte.

Meine Frage ist nun warum? Gibt elektrisch erstmal keinen Sinn, wenn galvanisch getrennt ist sollte ich das so lange betreiben können wie ich will?

- cad435

[Ing-Dom]

Was mich nun verwirrt ist, dass ich einige Statements so interpretiere, dass selbst wenn diese Trennung da ist (idr. wird ja ein USB-Isolator empfohlen) das Setup nicht dauerhaft betrieben werden sollte.

Meine Frage ist nun warum? Gibt elektrisch erstmal keinen Sinn, wenn galvanisch getrennt ist sollte ich das so lange betreiben können wie ich will?

Dabei geht es nicht um die Potentialtrennung sondern um ein Powerrail-Problem. übnlicherweise versorgen wir die Geräte über USB mit Spannung, und auch die USB-Isolatoren haben idr isolierte DC-DC drin. Damit man ohne KNX FW laden kann etc.. das führt dann bei unzureichender Entkopplung der Rails (was wir - aus Gründen der Komplexität bisher ider nur über eine Schottky gemacht haben) in bestimmten Fällen zu Problemen.

Bei deiner Schaltung sehe ich kein Problem.
Save brauchst du eigtl gar nicht, wenn der uC nicht aus der BCU versorgt wird. Macht dann nur Probleme.
Und warum nimmst du 1kanalige Isolatoren?

[cad435]

Ah ja passt, dann realisier ich das so.

Und warum nimmst du 1kanalige Isolatoren?

Weil ich von denen noch ca. 300 stück nutzlos rumliegen hab

[Ing-Dom]

ich habs mir fast gedacht

[cad435]

Ja die sind ehrlich gesagt auch maximal überdimensioniert und viel zu teuer, 4€ das Stück (Edit: TI direkt ruft sogar 6€/Stück auf, phu)...

Wenn ich die nicht rum liegen hätte würde ich wohl einen π131U31 (https://www.lcsc.com/datasheet/lcsc_...31_C471596.pdf) Verwenden. (26ct und JLCPCBA kann den direkt drauf bestücken)

Da die Anforderungen hier 115200Baud, max. 30C Umgebungstemperatur (schätzungsweise) und keine sicherheitsrelevanten Spannungen sind, tuts quasi das billigste was der Chinamarkt hergibt. Die MTBF ist bei so "Standardteilen" beim Chinesen halt mittlerweile auch nicht mehr höher als woanders.

Ansonsten, falls das wem zu "chinesisch" ist, den klassischen ISO7741 (1€, ebenfalls per JLCPCBA bestückbar)

[cad435]

So, wieder sinnvolle Frage zur Software:

Ich habe momentan 3 I2C's eingeplant:
image.png
Laut RP2040 Doku hat der chip zwei I2C Peripherals.
Die pinzuordnungen kann ich mit "setSDA/setSCL" im "laufenden Betrieb" umschalten, ja?

zumindest lese ich das so aus dem Sourcecode vom THPSensormodule

Richtig interpretiert?

[Ing-Dom]

ja - ist ja nur der GPIO multipexer..

[cad435]

So, jetzt gehts an die C Programmierung:

Frage zum verständniss:
Ich möchte Parameter nach dem Starten laden. Das tue ich in der Module::setup() function.

Müsste doch gehen, oder?

void TDD_Module::setup()
{
logTraceP("setup");
cap = new CAP1188(CAP1188_RST_PIN);

pinMode(TOUCH_PIN_TOP_LEFT, INPUT_PULLUP);
pinMode(TOUCH_PIN_TOP_RIGHT, INPUT_PULLUP);
pinMode(TOUCH_PIN_BOTTOM_LEFT, INPUT_PULLUP);
pinMode(TOUCH_PIN_BOTTOM_RIGHT, INPUT_PULLUP);
if (cap->begin(CAP1188_I2C_ADDR, new TwoWire(&CAP1188_I2C_WIRECLASS, CAP1188_I2C_SDA, CAP1188_I2C_SCL)))
{
logTraceP("CAP1188 begin success");
}
uint8_t sensititvity = knx.paramByte(TTD_CAP_Sensitivity); //Get the sensitivity from the parameter
cap->SetGlobalSensitivity(sensititvity); //Set the sensitivity of the CAP1188
uint8_t AnalogFilterEnabled = knx.paramByte(TTD_CAP_EnableAnalogFilter); //Get the touch threshold from the parameter
if (AnalogFilterEnabled == 1) //If the analog filter is enabled
cap->disableAnalogNoiseFilter(false); //Enable the analog filter
else //If the analog filter is disabled
cap->disableAnalogNoiseFilter(true); //Disable the analog filter
}

Edit:
Na da wahr ich wohl zu übereifrig.

So ist es wohl vom Erfinder gedacht worden:

cap->SetGlobalSensitivity(ParamTTD_CAP_Sensitivity); //Set the sensitivity of the CAP1188
cap->disableAnalogNoiseFilter(!ParamTTD_CAP_EnableAnal ogFilter); //Enable the analog filter

[cad435]

Direkt die Nächste Frage:

Der RP2040 ist ja DualCore.

Ich hoffe/gehe davon aus, dass der KNX-Stack auf Core0 (=loop()) läuft, damit müsste ich doch Core1 (=loop1()) als LED-Kern verwenden können, oder?

Was ich umsetzen will/muss nenne Ich immer "Frame-Machine" - einen fest getakteten Loop welcher alle 20ms aufgerufen wird. Das realisiert mir dann eine Framerate von 50Hz für die LED's. Natürlich nicht blockend, sondern über die Auswertung von millis()

[thewhobox]

Nicht ganz.
Wenn du DualCore aktiviert läuft auch noch die LED für den Core1 drauf.

Das was du brauchst klingt aber eher nach nem Timer.
Über Common kannst du den alarmPool weitere Timer hinzufügen.

[coko]

So ist es wohl vom Erfinder gedacht worden:

cap->SetGlobalSensitivity(ParamTTD_CAP_Sensitivity); //Set the sensitivity of the CAP1188
cap->disableAnalogNoiseFilter(!ParamTTD_CAP_EnableAn al ogFilter); //Enable the analog filter

Korrekt. Sofern Du nicht einen wirklich guten Grund hast, solle der Zugriff auf die Parameter immer mit die erzeugten Makros erfolgen.

Was ich umsetzen will/muss

Was genau willst Du denn umsetzen? MultiCore macht Debugging deutlich komplizierter.

[cad435]

Was genau willst Du denn umsetzen? MultiCore macht Debugging deutlich komplizierter.

Na das macht nix, die Low-Level LED-Funktionen dürfen ruhig weiterlaufen.
Ja ich weis, multicore ist schwer zu debuggen, aber ich glaube die funktionen sind unabhängig genug, dass man das eine unabhängig vom anderen debuggen kann.


Also, in Core1 läuft ein fixer loop der alle 20ms aufgerufen wird:

void TDD_Module::loop1()
{
    if (millis() - lastTimeLEDRun >= LEDFPSTime_ms) //If the time is up, run the LED's
    {
        FixedFPSLedLoop(); //Run the LED's
        lastTimeLEDRun = millis(); //Set the last time the LED was run to the current time
    }
}​

Dieser FixedFPSLedLoop() kümmert sich nur um die LED-Effekte (die werden jetzt erstmal fix einprogrammiert, Extra-Parametrierung muss sich mal hinten anstellen)

Alles was in diesem Loop läuft ist erstmal komplett KNX unabhängig

void TDD_Module::FixedFPSLedLoop()
{
    switch (ledState) //Switch the LED state
    {
        case STATIC: //If the LED's are static, do nothing
            break;
        case TODO: //If the LED's are sheduled for a change, prepare
            memcpy(leds_Original, leds_Current, RGB_LED_COUNT); //Copy the current LED's to the original LED's
            fadingAmount = 0; //Set the fading amount to 0
            ledState = RUNNING; //Set the LED state to running
            break;
        case RUNNING: //If the LED's are running, run them
            if (fadingAmount > 255)
                fadingAmount = 255; //If the fading amount is greater than 255, set it to 255
            blend( leds_Original, leds_Target, leds_Current, RGB_LED_COUNT,  (fract8)fadingAmount); //Blend the LED's to the target color
            fadingAmount += TTD_LED_TRANSITION_DELTA; //Increase the fading amount
            if (fadingAmount >= 255) //If the fading amount is greater than or equal to 255, set the LED's to the target color
            {
                memcpy(leds_Current, leds_Target, RGB_LED_COUNT); //Copy the target LED's to the current LED's
                ledState = STATIC; //Set the LED state to static
            }
            FastLED.show(); //Show the LED's
            break;  
        default:
            break;
    }
}​

Das anwerfen der Statemachine geschieht über einen externen Aufruf, nämlich zuerst das Array "leds_Target" befüllen, danach den ledState auf "todo" setzen.

Anschließened läuft die Statemachine durch bis die LED's im neuen zustand sind.

den ledState sollte man ggf. noch mit nem mutex versehen...