Support ValueChanged and DebounceTimeout in Lightning Provider

[CodeChief]

The current Lightning provider does not support the ValueChanged event or the DebounceTimeout property because, according to the source GpioDeviceProvider.h it says "Not implemented since Lightning does yet support interrupts yet".

I don't see any roadmap or milestone in GitHub. Can you please give us a hint how long it will be before we can use that.

Also when you implement it, please consider this feature request I made at the IoT forum (https://social.msdn.microsoft.com/Forums/en-US/af4018ad-5658-4048-86a0-ae13c994effb/gpio-drivers?forum=WindowsIoT see answer from MSFT Jordan Rhee), to add the timestamp to the event. It makes more sense then when PWM decoding and increases potential accuracy of software decoding.

[jessekaplan]

We're actively working on the interrupt support and expect to have it available within a few weeks.

For the timestamp request, we would have to update the in-box APIs and so that can't be added as part of a github update. We do like that feature request though and are looking at options for implementing it and getting it out there.

Thanks,
Jesse

[CodeChief]

Sounds great, thanks for replying so quickly 👍

[AlexandrSurkov]

Hello! Is there any news about ValueChanged supporting?

[jessekaplan]

We've been blocked on a few related issues, but have just cleared those up. They will be going up today.

--Jesse

[AlexandrSurkov]

Thanks!

[MahmoudGSaleh]

ValueChanged and DebounceTimeout are now supported in the latest Nuget. Note, the code for the Lightning providers has moved to the Lightning repository, with the binaries published to as part of the latest Lightning SDK Nuget package.

[andyfung]

I installed Microsoft IoT Lightning SDK 1.1.0-alpha. However, the ValueChanged still does not work.

[MahmoudGSaleh]

@andyfung What is the error you're getting? Can you share some code?

[andyfung]

I am running the sample code BlinkyBackground and PushButton from https://github.com/ms-iot/BusProviders/tree/develop/Microsoft.IoT.Lightning.Providers.

In BlinkyBackground, it is work well. But in PushButton, there is no interrupt with ValueChanged.

[MahmoudGSaleh]

Is the HW setup for the PushButton the same as the one here ?
If you push the button, do you get any feedback on the screen/red led?

[MahmoudGSaleh]

Also, are you using Raspberry Pi 2/3 or MBM?

[andyfung]

1. The HW setup is the same.
2. When I push the button, there is no led at all.
3. If I am not running with Lightning, PushButton works fine. That mean I installed back the "Inbox Driver" instead of "Direct Memory Mapped Driver" on web portal.

And I set breakpoint in the if statement shown as below, so I can tell lightning is enable or not:

        if (LightningProvider.IsLightningEnabled)
        {
            // Set Lightning as the default provider
            LowLevelDevicesController.DefaultProvider = LightningProvider.GetAggregateProvider();
            GpioStatus.Text = "GPIO Using Lightning Provider.";
        }
        else
        {
            GpioStatus.Text = "GPIO Using Default Provider.";
        }

When lightning is enabled, ValueChanged does not work.

[andyfung]

And I am running on Rasp Pi 2.

[MahmoudGSaleh]

@andyfung Thanks for your feedback.
I'll try to reproduce the issue with the same sample.

[andyfung]

Thanks a lot! I appreciated it.

[andyfung]

Hello! Any updated?
Thanks

[MahmoudGSaleh]

Apologies for the delay. I'm still unable to reproduce the issue with the latest Lightning SDK.
I'll try again tomorrow with a few different combinations.

[andyfung]

Thanks. Let me know if more information is needed from me.

[MahmoudGSaleh]

I figured you maybe using an older build of IOT Core. My guess, you're using 10586?
Unfortunately, the driver didn't support hardware interrupts then.
Can you try with a newer build? 14352 has the updated driver. If you're not already using the IOT Core Dashboard app, please follow this link to get it (or download directly from here).

Best regards,
Mahmoud

[andyfung]

Correct. i am using 10586 which the instruction told me. How can I get 14352?

[andyfung]

I flash my SD with IoT core which I got it from https://developer.microsoft.com/en-us/windows/iot/downloads

[MahmoudGSaleh]

To get 14352,

1- Please download and install the Windows IOT Core Dashboard from here. Also available from https://developer.microsoft.com/en-us/windows/iot/downloads
2. After the installation is complete, open the Dashboard application,
3. Go to "Setup a new device" page.
4. Choose your Device type: Raspberry Pi2, version: 14352 and the drive for the SD card.
5. Then, click Download and install to apply the image to the SD card.

[andyfung]

I have the Dashboard already. The problem is the device type doesn't show me 14352. It only show me "Windows IoT Core for Raspberry Pi 2".

[andyfung]

[MahmoudGSaleh]

My apologies! Looks like insider preview builds were not published yet.

You can still download Insider preview build 14342 from http://go.microsoft.com/fwlink/?LinkId=733603.
However, you'll need to join the Windows Insider program

[MahmoudGSaleh]

And, here are instructions to manually install an Insider build: https://developer.microsoft.com/en-us/windows/iot/win10/GetStartedManually.htm

[andyfung]

ValueChanged seems to work now. Thanks.

[MahmoudGSaleh]

@andyfung Thanks for confirming!

[CodeChief]

Unfortunately this is just not performing for PWM input (pulse length/timing) calculation. Because we didn't get the timestamp property I requested, it appears that the lower level (higher priority) event handling is now causing more of a delay to my user code. Meaning in end effect that attempts at "after the fact" PWM decoding are now worse!

Here are some actual values from the current Lightning provider (same PWM calculation code, only the driver setting is changed):

PWM Frame at 2256385689 1=2127 2=1552 3=1017 4=920 5=870 6=937 7=989 8=1010
PWM Frame at 2256406806 1=2196 2=1577 3=1199 4=917 5=943 6=1294 7=1283 8=1120
PWM Frame at 2256448267 1=1409 2=1489 3=963 4=1493 5=1017 6=1478 7=988 8=1001
PWM Frame at 2256490184 1=1474 2=1600 3=957 4=1448 5=952 6=1497 7=978 8=979
PWM Frame at 2256532250 1=1418 2=1501 3=958 4=1492 5=993 6=1614 7=919 8=959
PWM Frame at 2256553727 1=2441 2=1594 3=953 4=915 5=870 6=882 7=914 8=871
PWM Frame at 2256595171 1=1504 2=1482 3=993 4=1467 5=1005 6=1542 7=960 8=976
PWM Frame at 2256616812 1=2061 2=1961 3=1040 4=940 5=882 6=934 7=886 8=876
PWM Frame at 2256658227 1=1452 2=1498 3=969 4=1503 5=1038 6=1461 7=946 8=1002
PWM Frame at 2256700272 1=1492 2=1421 3=978 4=1482 5=981 6=1507 7=987 8=992
PWM Frame at 2256721829 1=2274 2=1728 3=1168 4=972 5=914 6=948 7=928 8=998
PWM Frame at 2256763248 1=1435 2=1489 3=970 4=1512 5=962 6=1522 7=985 8=985
PWM Frame at 2256805179 1=1496 2=1500 3=985 4=1585 5=1086 6=1337 7=955 8=984
PWM Frame at 2256826791 1=2005 2=1509 3=1255 4=984 5=876 6=843 7=901 8=947
PWM Frame at 2256868238 1=1463 2=1477 3=982 4=1499 5=973 6=1558 7=955 8=968
PWM Frame at 2256889756 1=2104 2=1733 3=1095 4=980 5=879 6=890 7=871 8=877
PWM Frame at 2256910760 1=2055 2=1374 3=1254 4=1036 5=880 6=871 7=926 8=967

Totally erratic, e.g. PWM value 1 was really about 1500 but varies here up to over 2400! In contrast, here are the results from the same code with the old "inbox" driver:

PWM Frame at 96264950 1=1333 2=1441 3=914 4=1468 5=990 6=1497 7=1061 8=946
PWM Frame at 96285890 1=1299 2=1504 3=949 4=1538 5=917 6=1503 7=987 8=994
PWM Frame at 96306958 1=1294 2=1437 3=928 4=1493 5=985 6=1502 7=990 8=996
PWM Frame at 96327960 1=1323 2=1382 3=950 4=1494 5=987 6=1502 7=989 8=1066
PWM Frame at 96349029 1=1239 2=1383 3=1041 4=1426 5=981 6=1501 7=984 8=999
PWM Frame at 96370020 1=1255 2=1413 3=930 4=1493 5=988 6=1500 7=994 8=991
PWM Frame at 96390953 1=1311 2=1434 3=928 4=1492 5=982 6=1503 7=994 8=990
PWM Frame at 96411942 1=1362 2=1425 3=1068 4=1380 5=926 6=1499 7=994 8=990
PWM Frame at 96432996 1=1312 2=1346 3=968 4=1497 5=986 6=1501 7=984 8=996
PWM Frame at 96454154 1=1132 2=1400 3=935 4=1499 5=983 6=1501 7=994 8=989
PWM Frame at 96474929 1=1267 2=1597 3=894 4=1441 5=979 6=1500 7=989 8=993
PWM Frame at 96496180 1=1146 2=1352 3=948 4=1499 5=982 6=1503 7=986 8=989
PWM Frame at 96517002 1=1314 2=1360 3=949 4=1500 5=986 6=1506 7=980 8=991
PWM Frame at 96538036 1=1339 2=1387 3=868 4=1495 5=982 6=1501 7=989 8=987
PWM Frame at 96558891 1=1501 2=1331 3=909 4=1489 5=989 6=1500 7=988 8=990

Still not perfect but at least within the same ballpark! If I activate my CPPM validity filter, which ensures that the low and high times are not beyond the CPPM standard maximum of "about" ~300 microseconds (I gave it 600 to account for manufacturer differences) then I get no data at all!

If I only had the timestamp available from the low level code (where and when the "fact" occurred), then my code would change to virtually no calculation at all, so the PWM values (both value and length) would be atomic and potentially useful for real world applications. I will open an issue requesting that small feature with this justification. Just one little timestamp value would make a world of difference to the possibilities.

[jessekaplan]

If you sign up for Windows Insider, the next preview build* of IoT Core will provide a timestamp, captured as early as possible, for each interupt. We'll also store them in a reasonably large (1 page) buffer so you don't have to service the events in real time to get the appropriate data. Please give it a try and let us know if it meets your needs.

We're working on better reconciliation between the in-box and direct memory mapped driver. That will be available in a future preview and we'll have more details as we get closer.

*There is a small chance that the new timestamp feature just missed the snap deadline for the upcoming flight. If it did, it will be in the next one.

[CodeChief]

Wow that is exactly what we need! That will close #42 when it is released 👍 I'm already using the insider build and downloaded the preview a few days ago, but I'll check again regularly until I see something new.

[mrajaraghavan]

ValueChanged is not working for me. I'm using Minnowboard Turbot dual core with windows iot build 16299. I have added Microsoft.IoT.Lightning v1.1.0. I wanted to capture an interrupt continuously (which is generated at an interval rate of less than 100 micro seconds) using a gpio as input pin. I'm able to set a gpio as output also. Now i need to use ValueChanged. Can anyone help me in this regard.