PulseInOut Module slow to respond / IO60p16 SDK not really available?

Archive
1

Hi all,
I recently bought a FEZ Hydra together with an PulseInOut module in an attempt, to read 8 PWM channels from a connected receiver.

Altough the basic reading works, it seems every call to ReadChannel takes roughly 40msecs to get a response. This way, I need >300msecs to read all 8 channels. For RC purposes, this is wayyyyyyy too slow.

Am I missing something here? There does not seem to be a possibility to read all 8 channels at the same time, and waiting 40msecs for each reading is, well, hard.

Second point, I bought an IO60p16 along. When I try to access it, VS2010 gives me only “equals, get hash code, get type, reset, to string”, but I found a number of examples where I should be able to access more. More meaning something useful with port read and write.

Again, I suppose the error is on my side, but I can’t seem to grasp what exactly is wrong?

Any help would be really appreciated!

2

Show us your code please

3

My pleasure… I use two variants to read…


using System.Collections;
using System.Threading;
using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Time;
using Microsoft.SPOT.Touch;                               // I import some more modules than necessary since I also try to use a T35 later on...

using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;

namespace GadgeteerApp1
{
    public partial class Program
    {
        int[] pwmhigh = new int[8];
        DateTime millistart;
        DateTime milliend;

        void ProgramStarted()
        {
            GT.Timer pwmReadTimer = new GT.Timer(100);
            pwmReadTimer.Tick += new GT.Timer.TickEventHandler(pwmReadTimer_Tick);
            pwmReadTimer.Start();
        }

        void pwmReadTimer_Tick(GT.Timer timer)                      // Variant 1, reading only PWM Channel 1
        {
            millistart = DateTime.Now;
            pulseInOut.ReadChannel(1, out pwmhigh[0], out pwmlow[0]);
            milliend = DateTime.Now;
            var millis3 = milliend - millistart;                                   // Here I get something between 30 and 40msecs (mostly 32-33, small peaks up to 40)
        }

        void pwmReadTimer_Tick(GT.Timer timer)                      // Variant 2, reading all 8 PWM Channels
        {
            millistart = DateTime.Now;
            for (int i = 1; i <=8; i++) {
              pulseInOut.ReadChannel(i, out pwmhigh[i-1], out pwmlow[i-1]);
            }
            milliend = DateTime.Now;
            var millis3 = milliend - millistart;                                   // Here I get something between 300 and 400msecs
        }

}
4

Don’t use event, it can be 3x faster.
But the driver is in C# code, use I2C - daisy link, we cannot expect it is fast like the firmware in native code.

5

For some methods on IO60P16, please visit here:
http://www.tinyclr.com/forum/topic?id=9784&page=3

6

@ Dat

To measure elapsed time I suggest the following code:

DateTime start  = DateTime.Now;

/// do your stuff

TimeSpan elapsed = DateTime.Now - start;

Subtracting DateTime.Millisecond values can have a problem with second rollover.

7

@ Mike -

Yes, your way is better :smiley:

8

Many thanks Dat, so my only “error” on this one was to use the Timer? I’ll make sure to test this asap, but from your post, it sure looks like that would be the cause. 90msecs, like you got, would be quite enough for my requirements, so I don’t think I have to tinker around with native code here. Just one more question… Should I decide to pick up another PulseInOutModule (I do need 16 PWM in and out) and daisy link it to this one, can I still expect the same performance?

Also many thanks for pointing me to the right thread with the IO60p16, I seemingly was too blind to find it myself :confused:

@ Mike good to know :slight_smile:

9

Ah, one more… If I ever would have too much time, is there a way to get the firmware code of the module to, eventually, adapt it?

10

Ehr, but… either I’m missing something really essential or… check the attachment, I still get my 300msecs :confused:

11

Try to declare all variables outside while loop,

12

You mean like this? Doesn’t seem to change much :confused:

I saw you compiled it on a spider? I don’t expect this is something related to me using a Hydra, is it?

13

Hydra should be faster, let us check it.

14

Thanks, please do. I don’t have a problem with shopping another board, as long as I can be certain that it works :slight_smile:

Alternatively, just to be sure that there’s nothing weird inbetween, you might send me your code so I can try that 1:1 on my hydra. But I suppose you have more hardware ressources on your side anyway :wink:

15

We found the problem. You are right. An answer will come later.

1 Like
16

Thanks Gus, I received the file, tried it and am now able to marvel at the speed of PWM reading :slight_smile:

Thanks to everyone involved in solving this, the performance of the module is now beyond what I had hoped for!