ms-iot / lightning Goto Github PK

I just started looking into the Lightning provider and the first thing I tried by I2C and I found an issue. The I2C device (returned by DeviceInformation) shows it as DISABLED but when using the Inbox Driver shows as ENABLED.

I have a RBPi2 B with Windows 10 IoT 10.0.14393.67

I enabled DMMD Driver and created a simple program that makes reference to:

• Microsoft.IoT.Lightning: 1.1.0
• Microsoft.IoT.SDKFromArduino: 1.1.1

Also enabled the extensions:

• Windows Desktop Extensions for the UWP: 10.0.14393.0
• Windows IoT Extensions for the UWP: 10.0.14393.0

Modified Package.aspxmanifest with

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
  xmlns:iot="http://schemas.microsoft.com/appx/manifest/iot/windows10"
  IgnorableNamespaces="uap mp iot">
....
  <Capabilities>
    <Capability Name="internetClient" />
    <iot:Capability Name="lowLevelDevices" />
    <DeviceCapability Name="109b86ad-f53d-4b76-aa5f-821e2ddf2141"/>
  </Capabilities>
</Package>

And with the following code:

public MainPage()
{
    this.InitializeComponent();

    if (LightningProvider.IsLightningEnabled)
    {
        LowLevelDevicesController.DefaultProvider = LightningProvider.GetAggregateProvider();
    }

    CreateAsync();
}

private async Task CreateAsync()
{
    var aqs = I2cDevice.GetDeviceSelector("I2C1");

    var i2cDevices = await DeviceInformation.FindAllAsync(aqs);
    var i2cDevices_ManualAQS = await DeviceInformation.FindAllAsync("System.Devices.InterfaceClassGuid:=\"{a11ee3c6-8421-4202-a3e7-b91ff90188e4}\" AND System.DeviceInterface.Spb.ControllerFriendlyName:=\"I2C1\"");
    var allDevices = await DeviceInformation.FindAllAsync();


    foreach (var device in allDevices)
    {
        System.Diagnostics.Debug.WriteLine($"{device.Id}  - {device.Name}");
    }
}

i2cDevices does not return any devices, but i2cDevices_ManualAQS returns 1 which is DISABLED (I manually changed the AQS to include enabled and disabled devices) and the allDevices shows there is a I2C1 device in it (\\?\ACPI#MSFT8000#1#{a11ee3c6-8421-4202-a3e7-b91ff90188e4}\I2C1)

If I changed the driver to Inbox Driver i2cDevices has 1 device and it is ENABLED.

So, either DeviceInformation is returning incorrect data or the I2C device is not enable with using Lightning.

Thank you!

Discovered due to:
Need to define and map uint_farptr_t to const char *

Look here for all types:
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

Hello together,

the ValueChanged event of a GPIO Pin gets never called using the lightning providers with MinnowBoard MAX.

Is the ValueChanged event still not supported with MinnowBoard MAX and Windows IoT Core 15063.0?

LowLevelDevicesController.DefaultProvider = LightningProvider.GetAggregateProvider();
var gpioController = GpioController.GetDefault();
var pin = gpioController.OpenPin(0);
pin.SetDriveMode(GpioPinDriveMode.Input);
pin.ValueChanged += (gpioPin, args) =>
{
//Gets never called
};

When using I2C and calling

var settings = new I2cConnectionSettings(address) { SharingMode = I2cSharingMode.Shared };
var newDevice = _controllers[i2cChannel].GetDevice(settings);

If I call it a second time using the same controller with a different address I get an exception that the file is already in use. I suspect the backend stream isn't honoring I2cSharingMode

Anyway in trying to bypass the problem I tried using the same device and changing the SlaveAddress but that only resulted in the initial controller been used.

var dev = _devices[device.Channel];
dev.ConnectionSettings.SlaveAddress = device.Address;

I mean, is there a better way nowadays to work with PWM?
Thanks in advance.

in analogRead, ioPin is not initialized to a value. in the board switch statement:
case BoardPinsClass::BOARD_TYPE::MBM_BARE:
case BoardPinsClass::BOARD_TYPE::PI2_BARE:
// Translate the pin number to a fake pin number.
if (pin < A0)
{
ioPin = A0 + pin;
}
break;
default:
ThrowError(hr, "Unrecognized board type: 0x%08x", board);
}

// Perform the read.
hr = g_adc.readValue(ioPin, value, bits);

if (FAILED(hr))
{
    ThrowError(hr, "Error performing analogRead on pin: %d, Error: 0x%08x", pin, hr);
}

this means if I accidentally pass a bad pin, there is no trap and it falls through and used without being initialized.

Hi, from my point of view, the current behaviour of debouncing is incorrect:
When attaching a switch to ground with Pullup to Vcc and pressing the button, the ValueChangedEvent is fired each time the state is flapping (in my test scenario it is about 20 times per button press). Please refer to this thread: https://social.msdn.microsoft.com/Forums/en-US/dcb31681-9eda-4c97-9fd6-c5a7e94df147/gpio-input-pin-debouce-timeout-being-ignored?forum=WindowsIoT

I think, debouncing should filter the flapping from the input and firing the event only, when the state change (e.g. High -> Low) is still present after a certain time (DebounceTimeout).
The following line in your code, I think, is not working correctly:

in Providers/GpioDeviceProvider.h line 127:
if (eventTimeDiff >= pin->_DebounceTimeout.Duration || (eventTimeDiff > 0 && InfoPtr->NewState != pin->_lastEventState))

The first part of the if statement is okay. Second part: (eventTimeDiff > 0) will be almost always be true because flapping takes places in timeranges of a few milliseconds. (NewState != lastState) will also be true when an input flaps between High and Low.
As a result, a "high frequency" bouncing pin will result in many event callbacks. I think, the line should be replaced by this one:
if (eventTimeDiff >= pin->_DebounceTimeout.Duration || pin->_DebounceTimeout.Duration == 0)
If no debounce Timeout is set, then the user is not interested in debouncing so the event can be fired very time the pin changes it state. Otherwise a debounce timeout should be passed before firing the event.

I tried this code in my scenario with a debounce timeout of 50ms and this was working like a charm.

I have been trying to create a GpioProvider for the standard MCP230xx chips. These are basic GPIO expansion IC's and are very popular. I'd like my library to work just like the built in GpioPin's so that other code can simply use the GpioPin references no matter what the controller.

However, after implementing the necessary classes (C#)

public sealed class MCP23008GpioPinProvider : IGpioPinProvider
public sealed class MCP23008GpioControllerProvider : IGpioControllerProvider
public sealed class MCP23008GpioProvider : IGpioProvider

Using both the sample and the Lightning bus provider as a guide, these seem to work, with one MAJOR issue. When the app closes, the device is NOT released. So the next time the app starts it can no longer access the resource. The only way around this is a complete power cycle of the OS.

I have tried adding IDisposable interfaces on all classes to make sure that the instances are disposed right away, but it appears that when an app shuts down, none of this code is called (my main page view's Dispose never gets called).

What could I be missing?

As an aside, if the IGpioPin class was not marked internal this would be a lot easier. I could just create my own GpioPin class and use the interface in the contracts. But I am trying to do it the way MS has documented.

If you want all the code, I'd be happy to provide it.

Roy

This will enable Arduino's String object in our Lightning Wiring template

I have exactly the same code and it does not work using the Lightning drivers (Direct Memory Mapped) vs. the standard drivers (Inbox) on an RPi 3B. The interrupt is seen once with the Direct Memory Mapped driver, and it never fires again. Please note that the interrupt works perfectly with the standard Inbox drivers.

The code follows. The irq_gpio4_ValueChanged() function is the critical issue. This interrupt fires at a 30 Hz rate generated from external hardware input to gpio4.

The code is compiled against the latest 17763 API, latest stable Lightning release, and is running on the 17763 build on the RPi 3B.

register.zip

Hi, after going through the repository, I was unable to find the implementation of the InputPullDown mode offered by most controllers. Is there any chance to implement this for the Pi?

Windows.Devices.Gpio Drive Mode Reference:
https://docs.microsoft.com/en-us/uwp/api/windows.devices.gpio.gpiopindrivemode

Where can I find the source code for the Microsoft Bus Driver that implements the DMAP capability?
or alternatively where the DMAP interface protocol is defined?
I have an error DMAP_E_INVALID_LOCK_HANDLE_SPECIFIED when attempting to attach an interupt to a GPIO pin and can't figure out what is missing to cause it.

The value of DEFAULT_LENGTH is -1, so the exit criteria of the "then" portion of the ternary operator is never tested. Therefore, only the "if" portion determines the exit criteria (the null terminator '\0'). This results in no length protection, which is the purpose of the len parameter.

Pins 2 & 3 not able to use as PWM. Initialization fails with SEHException.

The PROGMEM keyword is only defined in AVR contexts but needs to exist in Lightning so existing Arduino examples will work.

#define PROGMEM
Add to pgmspace.h

I was looking at the performance document I found here

https://raw.githubusercontent.com/ms-iot/content/develop/en-US/Docs/LightningPerformance.md

They look kind of old so I was searching for the code which generated them and can't find it to run them against the latest bits.

Could the performance statistics be refreshed or the code release to allow us to do it ?

As the title states, this API which exists since the Creators update does throws an exception when trying to create an instance of it while using the lightning driver.

Spi.h on Arduino supplies a constant SS, which allows code that uses SPI to be portable across Arduino boards and compatibles (like Windows DMAP for example).

Need to define and map strlen_PF() to strlen()

The new hardware unit test which was checked in does not pass due to PWM A1-A8 not initializing correctly. Only on a full chip reset does it behave as expected.

There are lots of information on the Internet that RPi2 has hardware PWM support, and there are examples of how to use it with Linux libraries implementations (like WiringPi). On Windows 10 IoT, however, the only options are the software emulation on a GPIO pin and an external chip (and the only one is supported). So I'm wondering what prevents from implementing support for the hardware already on board?

The following definiton in pgmspace.h is missing a closing paren. This causes compiler errors complaining about a missing paren.

The early version of the lib/dll worked with console app.
The actual version can't be loaded, I think because Desktop UWP SDK Extensions are required .
Please remove this constraint, it make no sense to have this limitation for a lib that have to gives access to hardware resources.

Thank You.
Regards,
CAP