IOButtonState

Have you seen the Flyport Programmers Guide?

I think the programmers guide is actually very good and detailed. Everything described in that guide works like a charm for me.

Maybe it would be good if you could upload your project?

Regards,

Michael

Hi!

If you use IOInit with inup parameter, you have to connect a button between the input pin and the ground.

If you use IOInit with indown parameter, you have to connect the button between the input pin and the 3.3V...

You can see the webinars on the download section to better understand the difference between inup and indown.

Please, post also your code, as we can better help you

Take a look at the datasheet:

http://www.eikonsite.it/u/pd/33_flyport%20wifi%20datasheet%20rev7.pdf

Hello!

I think I've found a problem with this function. The function shoud return pressed, released or no change. I've found, that the sometimes the pressed or released status is not returned and managed to pinpoint the cause in the source code:

static DWORD tdebounce1 = 0;
int IOButtonState(int io)
{
DWORD tdebounce2;
tdebounce2 = TickGetDiv256();
if ((tdebounce2-tdebounce1)>5)
{
  io = io - 1;
  int stat;
  stat = Status [io];
 
  if (IOGet(io+1) > stat)
  {
   if (IOMode[io] == 2)
   {
    tdebounce1 = TickGetDiv256();
    return 1;
   }
   else 
   {
    tdebounce1 = TickGetDiv256();
    return 2;
   }
  }

  if (IOGet(io+1) < stat)
  {
   if (IOMode[io] == 2)
   {
    tdebounce1 = TickGetDiv256();
    return 2;
   }
   else
   {
    tdebounce1 = TickGetDiv256();
    return 1;
   }
  }
  if (stat == Status[io])
   return 0;
  return -1;
}
return 0;
}

If the value of the pin changes between first if statement (if (IOGet(io+1) > stat)) and second if statement (if (IOGet(io+1) > stat)) then the "event" is missed. In my case, I have a pull up resistor and the release "event" is sometimes missed.

The solution would be to read the value of the pin after the line (stat = Status [io];) and then use this value in the if statement (I have coded this by hand, so don't this code for 100%):

static DWORD tdebounce1 = 0;
int IOButtonState(int io)
{
DWORD tdebounce2;
tdebounce2 = TickGetDiv256();
if ((tdebounce2-tdebounce1)>5)
{
  io = io - 1;
  int stat;
  stat = Status [io];
  int pinVal;
  pinVal = IOGet(io+1);
  if (pinVal > stat)
  {
   if (IOMode[io] == 2)
   {
    tdebounce1 = TickGetDiv256();
    return 1;
   }
   else
   {
    tdebounce1 = TickGetDiv256();
    return 2;
   }
  }

  if (pinVal < stat)
  {
   if (IOMode[io] == 2)
   {
    tdebounce1 = TickGetDiv256();
    return 2;
   }
   else
   {
    tdebounce1 = TickGetDiv256();
    return 1;
   }
  }
  if (stat == Status[io])
   return 0;
  return -1;
}
return 0;
}

Am I missing something or am I right about this?

Hi Whitewater, good advice! But in any case the IOButtonState is a function thought to be polled continously, so the event lost in an iteration can be catch in the next... ;) However i'm thinking  about rewriting it using the change notification interrupt... so wouldn't need to be polled

Hi, Gabriele! Actually, the event is lost, because the transition from ON to OFF means "released" and if the event is not "triggered", the pressed event has to occur again before "released" is triggered again.

If I may suggest a further improvement ... The debounce function should test several concurent readings on a pin (in a certain timeframe) and consider a valid input only if several concurent readings show the same value (lets say check the pins every 1ms and consider the value only if 10 concurent readings show the same value).

I know this is a big overhead in CPU time, but it provides the most stable button read function.

I'm not exactly clear on how the change notification interrupt functions, so maybe that would be an option too.