• That's great!

    Actual status, compared to direct_io branch is: switched fast io off (return false in jshGetPinAddress)

    If you switched off fast IO, I believe you could just switch back to the master branch and forget about direct_io? All the other speed improvements are already pushed into master.

    IMO direct_io would be great if we could get it working though.

    how do we call task relevant RTOS function ? We could use #ifdef ESP32 or #ifdef RTOS. I would prefer the 2nd one.

    There's actually already jshInterruptOn() and jshInterruptOff() - would those do what's needed, or is that overkill?

    But yes, feel free to add an RTOS define to the Makefile and use #ifdef RTOS - I guess something like #ifdef FREERTOS may already exist?

    do we need jshIsPinValid(d->pins[n]) in jswrap_io_shiftOutCallback ? Isn't this already done in jswrap_io_shiftOut ?

    Yes, it's still needed. The check is only done when setting pin state.

    The idea is you might be able to call it with pins = [D0,undefined,undefined,undefined,undefi­ned,D1] if maybe you only wanted to use certain bits from the data you were sending. We could remove that functionality and make jswrap_io_shiftOut error if a pin couldn't be found though? That might be more sensible.

    If you wanted to make it faster you could change the test to: d->pins[n] != PIN_UNDEFINED though?

    In terms of speeding up IO, could you move gpio_matrix_out from jshPinSetValue into jshPinSetState? I think that should give you a bit extra:


  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Additional device for Espruino to support 8 pins in parallel (for discussion)

Posted by Avatar for JumJum @JumJum