Servo outputs appearing on wrong pin

[DaveAtKitronik]

Testing the Access:Bit with V2. The code:

This has a servo on P0 and a buzzer on P1. The block automatically reassigns the pitch pin to P1, so the onboard buzzer does not sound, it also centres the servo. It does this via a call to an initialisation routine which is only called the first time any access:bit block is used. However it is noticable that the buzzer makes a noise when a servo move is requested (on P0). using croc clips to 'miswire' the access bit so the servo is connected to P1 results in the servo moving when a beep block is called. (press either button A ot B in the test code)

[finneyj]

Hi @DaveAtKitronik

I'm just trying to create a simpler repro of this so i can analyze what might be happening. I'm curious about one particular thing:

Just like on v1, the v2 shares a single PWM peripheral for all pins. This means you can only have a single PWM period for all pins... so assuming this all worked on a v1, I'm curious how you managed to drive both a servo and sound output? Or is your extension simply always beeping at 50Hz and controlling it's volume using setAnalogValue() ?

[finneyj]

ah, I see... that'll be your secret incantation....

    function secretIncantation(): void {
        pins.servoWritePin(AnalogPin.P0, 90);
        basic.pause(1000);
        pins.digitalWritePin(DigitalPin.P0, 0);     //digital write 0 so the servo is not driven and does not interfere with the analog pitch pin
        pins.analogSetPitchPin(AnalogPin.P1);

        //set the initalised flag so we dont come in here again automatically
        initalised = true
    }

[DaveAtKitronik]

A cunning workaround...

[jaustin]

@DaveAtKitronik could you please try this alongside the SetSilenceLevel API (to set silence level to 0) so that we can see if this is a result of the pin dropping from the 'DAC 0' to 'real 0'

[DaveAtKitronik]

@jaustin What is the SetSilenceLevel API?

[abchatra]

@DaveAtKitronik @jaustin is this still an issue?

[DaveAtKitronik]

AS far as I know it is still broken

[martinwork]

Sample program below has button A => move barrier; B => beep After reset, pressing A doesn't buzz on P1, but after pressing B to beep, pressing A does buzz in P1.

P1.setAnalogValue(0), does not disconnect the pin from PWM.

Adding P1.setDigitalValue(0) after the beep fixes it, as does modifying setAnalogueValue to divert 0 and 1023 to setDigitalValue. https://github.com/martinwork/codal-nrf52/blob/master/source/NRF52Pin.cpp#L356

Without either of those fixes, when setServoValue calls setServoPulseUs, which simply calls pwm->setPeriodUs(20000), it doesn't rescale all the PWM buffer values for other channels, as happens in setAnalogPeriodUs. Then P1's buffer value is no longer at COUNTERTOP. https://github.com/martinwork/codal-nrf52/blob/master/source/NRF52Pin.cpp#L621

Does that make sense @finneyj?

MakeCode https://makecode.microbit.org/_i7eC3o3HuTak

C++

#include "MicroBit.h"

MicroBit uBit;

bool isup = true;

void onButtonA(MicroBitEvent e)
{
    isup = !isup;

    uBit.io.P0.setServoValue(isup ? 0 : 90);
    uBit.sleep(1000);
    uBit.io.P0.setDigitalValue(0);
}

void onButtonB(MicroBitEvent e)
{
    uBit.io.P1.setAnalogValue(512);
    uBit.io.P1.setAnalogPeriodUs(1000000/1025);
    uBit.sleep(1000);
    uBit.io.P1.setAnalogValue(0);
    uBit.sleep(1000);
}

int  main()
{
    uBit.init();

    uBit.io.P0.setServoValue(90);
    uBit.sleep(1000);
    uBit.io.P0.setDigitalValue(0);

    uBit.messageBus.listen( MICROBIT_ID_BUTTON_A,  MICROBIT_BUTTON_EVT_CLICK, onButtonA);
    uBit.messageBus.listen( MICROBIT_ID_BUTTON_B,  MICROBIT_BUTTON_EVT_CLICK, onButtonB);

    release_fiber();
    return 0;
}

[martinwork]

Created https://github.com/lancaster-university/codal-microbit-v2/issues/175