I have a touchscreen hw, I was rewritten the example modul for touchscreen server (i2c)... The example implemented by channels. Here I try to use interface. The hw abstraction layer interface reports if a new (filtered) position is ready, and one interface function is given for getting the actual position. This is running in an endless loop, as usual. There are no buffering, only one last calculated value pair is stored. When hw gives a ts_irq signal, we do some communication task w the hw, then latest value is stored. So there is a select case, which one starts doing its task when pin state changed. There is a timer case too in the same select, which periodically checks , if the last position was already sent, or not yet... Furthermore, the interface functions are handled in the same select block too... Therefore, I guess it is running in same thread. If the core is running in the communication branch, the interface case have to wait for the other case finished its task (and breaks) then new loop begins...
Code: Select all
interface ts2app_i {
[[notification]] slave void touch();
[[clears_notification]] {unsigned, unsigned} pop();
};
...
while(1){
select{
case ts_irq when pinseq(0):>int:{
get_touch_coords(i2c, ts_x, ts_y);
scale_coords(ts_x, ts_y);
if (ts_touched<10000) ts_touched++; //semaphore and counter in one
} break;
case ts2app.pop() -> {unsigned x, unsigned y}: { //we set the debug pin when this fn called.
x=ts_x; y=ts_y; //coordinates
} break;
case tmr when timerafter(t):>void:
if (ts_touched) {
ts2app.touch(); //report to app layer, we have a new value
ts_touched=0;
}
tmr:>t;
t+=period;
break;
}//select
}//while
I've some measurements. The screen contains two different situation, the first is when the hw is working(i2c bus communication running because the touch_irq input is active), the second one is a situation when the i2c bus not driven actually (there was no irq).
The first logical level is a debug output which is rising before we calls pop() function of the interface, and the signal returns to zero when this function call returns to the caller. As you can see in the code, there's nothing to do, only to get the x,y coordinates and returns with it to the caller. The second logic level is the i2c bus serial clock. So there we can see if we are in the worker case, which one communicates with the external device.
So , we can see clearly on the second plot, if the pop() function called when no other case was activated, it can run immediately, and returns less than half usec. But, on the first plot we can see, the pop() function waits for the other running case branch aprox 800usec.
Yes, it can be still a good implementation... But, I think it could be a better design, if another layer need no wait for the results. Even if I don't want to waste more channels or a separated fifo task to do this... So , can be better if I use the higher level's interface clients side rather than implementing this server interface for the touchscreen service?