search

ms-iot / BusProviders

Repository for Windows IoT Core Bus Provider Libraries
MIT License
40 stars 44 forks source link

Support ValueChanged and DebounceTimeout in Lightning Provider #26

Closed CodeChief closed 8 years ago

CodeChief commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Sounds great, thanks for replying so quickly :+1:

AlexandrSurkov commented 8 years ago

Hello! Is there any news about ValueChanged supporting?

jessekaplan commented 8 years ago

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

--Jesse

AlexandrSurkov commented 8 years ago

Thanks!

MahmoudGSaleh commented 8 years ago

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 commented 8 years ago

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

MahmoudGSaleh commented 8 years ago

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

andyfung commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

andyfung commented 8 years ago

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 commented 8 years ago

And I am running on Rasp Pi 2.

MahmoudGSaleh commented 8 years ago

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

andyfung commented 8 years ago

Thanks a lot! I appreciated it.

andyfung commented 8 years ago

Hello! Any updated? Thanks

MahmoudGSaleh commented 8 years ago

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 commented 8 years ago

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

MahmoudGSaleh commented 8 years ago

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). dashboard Best regards, Mahmoud

andyfung commented 8 years ago

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

andyfung commented 8 years ago

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

MahmoudGSaleh commented 8 years ago

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

  1. After the installation is complete, open the Dashboard application,
  2. Go to "Setup a new device" page.
  3. Choose your Device type: Raspberry Pi2, version: 14352 and the drive for the SD card.
  4. Then, click Download and install to apply the image to the SD card.
andyfung commented 8 years ago

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 commented 8 years ago

image

MahmoudGSaleh commented 8 years ago

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 commented 8 years ago

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

andyfung commented 8 years ago

ValueChanged seems to work now. Thanks.

MahmoudGSaleh commented 8 years ago

@andyfung Thanks for confirming!

CodeChief commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Wow that is exactly what we need! That will close #42 when it is released :+1: 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 commented 6 years ago

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.