Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

Beremiz-Devel mailing list

Hi, Mario!

Yes,
task management must be passed to the target system! And Yes it is big change!

But,

Maybe I did not fully describe my workaround:
I'm talking about calculating "greatest_tick_count__" in matiec
In file matiec/stage4/generate_c.cc line 663:

    unsigned long get_greatest_tick_count(void) {
      unsigned long long least_common_tick = least_common_ticktime / common_ticktime;
      if (least_common_tick >> 32)
        ERROR;
      return (unsigned long)(~(((unsigned long)-1) % (unsigned long)least_common_tick) + 1);
    }

"replace" it function!

One problem is solved (the time between calls of the task during overflow __tick), another appears: it can happen that the values unsigned long do not suffice for all interval task!


12.04.2018 16:38, [hidden email] пишет:
 HI Aleksandr,

 Yes, it seems that this would fix the problem you mentioned.

 However, my opinion is that if we are going to mess around with this code, it 
would be better if we could fix this properly. What I mean by this is that:

0) Recognize that it should not be the compiler's (matiec) responsibility to 
include code that calls the tasks periodically. This functionality should be 
provided instead by the runtime environment.


1)
  The compiler (matiec) should simply set up an array of struct with the 
information required to execute the tasks periodically.

typedef task_into_t {
  int period;
  void (*func) (void);
  ...
} 

task_info_t task_info[3] = {
  {3, task0},
  {10, task1}
};


2)
 It should then be up to the runtime to do what it needs to call the tasks 
periodically.
 When running on a POSIX operating system, tasks may be mapped onto threads.
 When running on an embedded system with no operating system, then the cyclic 
scheduler (while(1) loop) may be used instead.


 NOTE: This means that all runtime systems currently using Beremiz/matiec will 
need to be updated, which is why I have been putting off this change.


 Cheers,

    Mario.

-- 
С уважением,
Сафронов Александр
Инженер отдела разработки
ООО "К-СОФТ ИНЖИНИРИНГ"
Best Regards,
Safronov Aleksandr
Developer, Firmware Development Team
LLC "K-SOFT ENGINEERING"

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

Beremiz-Devel mailing list


 Hi Aleksandr

On Thursday, April 12, 2018 17:06:40 [hidden email]
wrote:
> Hi, Mario!
>
> Yes,
> task management must be passed to the target system! And Yes it is big
> change!

 At the moment, I don't think this is such a big change.
 It requires the collaboration of several people, but the change itself does
not seem to be so big.

 Most runtime implementations will simply copy the code that is currently
generated by matiec and paste it into the runtime code. A little more glue
code will be necessary, but it does not seem like that much work...


>
> But,
>
> Maybe I did not fully describe my workaround:
(...)

 Hmmm. I think I was able to understood you approach.


> One problem is solved (the time between calls of the task during
> overflow __tick), another appears: it can happen that the values
> unsigned long do not suffice for all interval task!
>

 This is what I am trying to avoid.
 We should simply push the responsibility of handling all these issues down to
the runtime/target system.




  Mario



> 12.04.2018 16:38, [hidden email] пишет:
> >   HI Aleksandr,
> >  
> >   Yes, it seems that this would fix the problem you mentioned.
> >  
> >   However, my opinion is that if we are going to mess around with this
> >   code, it>
> > would be better if we could fix this properly. What I mean by this is
> > that:
> >
> > 0) Recognize that it should not be the compiler's (matiec) responsibility
> > to include code that calls the tasks periodically. This functionality
> > should be provided instead by the runtime environment.
> >
> >
> > 1)
> >
> >    The compiler (matiec) should simply set up an array of struct with the
> >
> > information required to execute the tasks periodically.
> >
> > typedef task_into_t {
> >
> >    int period;
> >    void (*func) (void);
> >    ...
> >
> > }
> >
> > task_info_t task_info[3] = {
> >
> >    {3, task0},
> >    {10, task1}
> >
> > };
> >
> >
> > 2)
> >
> >   It should then be up to the runtime to do what it needs to call the
> >   tasks
> >
> > periodically.
> >
> >   When running on a POSIX operating system, tasks may be mapped onto
> >   threads.
> >   When running on an embedded system with no operating system, then the
> >   cyclic>
> > scheduler (while(1) loop) may be used instead.
> >
> >   NOTE: This means that all runtime systems currently using Beremiz/matiec
> >   will>
> > need to be updated, which is why I have been putting off this change.
> >
> >   Cheers,
> >  
> >      Mario.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

Beremiz-Devel mailing list
Hi, Alexander and Mario!

How about less radical approach?

/*Currently we have the code like*/
BOOL TIMER0;
BOOL TIMER1;

/*...*/

void RESOURCE1_run__(unsigned long tick) {
  TIMER0 = !(tick % 25);
  TIMER1 = !(tick % 1);

  if (TIMER0) {
    Task1_body__(&PER5);
  }
  if (TIMER1) {
    Task2_body__(&PER3);
  }
}

/*Let us change it to something like*/
/*...*/

#define IEC_SCHED_TIMER(t)    __time_cmp(__CURRENT_TIME, t)
#define IEC_SCHED_SETTM(t, s) (t = __time_add(t, s))

/*...*/

#ifndef IEC_TASK_RUN
/*Default implementation*/
#define IEC_TASK_RUN(a,b)  a##_body__(&(b))
#endif /*IEC_TASK_RUN*/

/*...*/

IEC_TIME TIMER0;
IEC_TIME TIMER1;

/*...*/

void RESOURCE1_run__(unsigned long tick) /*May be keep backward compatible API?*/
{
  if (IEC_SCHED_TIMER(TIMER0) > 0)
  {
    IEC_SCHED_SETTM(TIMER0, TIMER0_TICK_TIME);
    IEC_TASK_RUN(Task1, PER5);
  }

  if (IEC_SCHED_TIMER(TIMER1) > 0)
  {
    IEC_SCHED_SETTM(TIMER1, TIMER1_TICK_TIME);
    IEC_TASK_RUN(Task2, PER3);
  }
}

In such case we may keep things backward compattible, but give users the abbility to use any tasking implementation...

Best regards,
Paul Beltyukov

2018-04-12 23:17 GMT+05:00 <[hidden email]>:


 Hi Aleksandr

On Thursday, April 12, 2018 17:06:40 [hidden email]
wrote:
> Hi, Mario!
>
> Yes,
> task management must be passed to the target system! And Yes it is big
> change!

 At the moment, I don't think this is such a big change.
 It requires the collaboration of several people, but the change itself does
not seem to be so big.

 Most runtime implementations will simply copy the code that is currently
generated by matiec and paste it into the runtime code. A little more glue
code will be necessary, but it does not seem like that much work...


>
> But,
>
> Maybe I did not fully describe my workaround:
(...)

 Hmmm. I think I was able to understood you approach.


> One problem is solved (the time between calls of the task during
> overflow __tick), another appears: it can happen that the values
> unsigned long do not suffice for all interval task!
>

 This is what I am trying to avoid.
 We should simply push the responsibility of handling all these issues down to
the runtime/target system.




  Mario



> 12.04.2018 16:38, [hidden email] пишет:
> >   HI Aleksandr,
> >   
> >   Yes, it seems that this would fix the problem you mentioned.
> >   
> >   However, my opinion is that if we are going to mess around with this
> >   code, it>
> > would be better if we could fix this properly. What I mean by this is
> > that:
> >
> > 0) Recognize that it should not be the compiler's (matiec) responsibility
> > to include code that calls the tasks periodically. This functionality
> > should be provided instead by the runtime environment.
> >
> >
> > 1)
> >
> >    The compiler (matiec) should simply set up an array of struct with the
> >
> > information required to execute the tasks periodically.
> >
> > typedef task_into_t {
> >
> >    int period;
> >    void (*func) (void);
> >    ...
> >
> > }
> >
> > task_info_t task_info[3] = {
> >
> >    {3, task0},
> >    {10, task1}
> >
> > };
> >
> >
> > 2)
> >
> >   It should then be up to the runtime to do what it needs to call the
> >   tasks
> >
> > periodically.
> >
> >   When running on a POSIX operating system, tasks may be mapped onto
> >   threads.
> >   When running on an embedded system with no operating system, then the
> >   cyclic>
> > scheduler (while(1) loop) may be used instead.
> >
> >   NOTE: This means that all runtime systems currently using Beremiz/matiec
> >   will>
> > need to be updated, which is why I have been putting off this change.
> >
> >   Cheers,
> >   
> >      Mario.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

Beremiz-Devel mailing list

 Hi Paul,


 Yes, the idea of keeping both options open is great.

 My suggestion (to keep backward compatibility) is to keep the generated code
exactly as it is.  This keeps backward compatibility.

 To add support for new scheduling methods, we add the
typedef struct  {
 int period;
 void (*fptr)(void);
 ...
} task_into_t;

task_into_t tasks[] = {
  {3, Task0_run},
  {10, Task1_run},
...
};

Add functions for each task:
 Task0_run();
 Task1_Run();
...



 It is then up to the runtime/target system what to do.

 It can either:
   - use usual/current method
         call Config_init() and Config_Run();
  - new method
         call Config_init() and set up threads (or whatever)
        to call the tasks at the correct times.



 Comments?


   Cheers,

        Mario.






On Friday, April 13, 2018 10:04:34 [hidden email] wrote:

> Hi, Alexander and Mario!
>
> How about less radical approach?
>
> /*Currently we have the code like*/
> BOOL TIMER0;
> BOOL TIMER1;
>
> /*...*/
>
> void RESOURCE1_run__(unsigned long tick) {
>   TIMER0 = !(tick % 25);
>   TIMER1 = !(tick % 1);
>
>   if (TIMER0) {
>     Task1_body__(&PER5);
>   }
>   if (TIMER1) {
>     Task2_body__(&PER3);
>   }
> }
>
> /*Let us change it to something like*/
> /*...*/
>
> #define IEC_SCHED_TIMER(t)    __time_cmp(__CURRENT_TIME, t)
> #define IEC_SCHED_SETTM(t, s) (t = __time_add(t, s))
>
> /*...*/
>
> #ifndef IEC_TASK_RUN
> /*Default implementation*/
> #define IEC_TASK_RUN(a,b)  a##_body__(&(b))
> #endif /*IEC_TASK_RUN*/
>
> /*...*/
>
> IEC_TIME TIMER0;
> IEC_TIME TIMER1;
>
> /*...*/
>
> void RESOURCE1_run__(unsigned long tick) /*May be keep backward compatible
> API?*/
> {
>   if (IEC_SCHED_TIMER(TIMER0) > 0)
>   {
>     IEC_SCHED_SETTM(TIMER0, TIMER0_TICK_TIME);
>     IEC_TASK_RUN(Task1, PER5);
>   }
>
>   if (IEC_SCHED_TIMER(TIMER1) > 0)
>   {
>     IEC_SCHED_SETTM(TIMER1, TIMER1_TICK_TIME);
>     IEC_TASK_RUN(Task2, PER3);
>   }
> }
>
> In such case we may keep things backward compattible, but give users the
> abbility to use any tasking implementation...
>
> Best regards,
> Paul Beltyukov
>
> 2018-04-12 23:17 GMT+05:00 <[hidden email]>:
> >  Hi Aleksandr
> >
> > On Thursday, April 12, 2018 17:06:40 [hidden email]
> >
> > wrote:
> > > Hi, Mario!
> > >
> > > Yes,
> > > task management must be passed to the target system! And Yes it is big
> > > change!
> >  
> >  At the moment, I don't think this is such a big change.
> >  It requires the collaboration of several people, but the change itself
> >
> > does
> > not seem to be so big.
> >
> >  Most runtime implementations will simply copy the code that is currently
> >
> > generated by matiec and paste it into the runtime code. A little more glue
> > code will be necessary, but it does not seem like that much work...
> >
> > > But,
> >
> > > Maybe I did not fully describe my workaround:
> > (...)
> >
> >  Hmmm. I think I was able to understood you approach.
> >  
> > > One problem is solved (the time between calls of the task during
> > > overflow __tick), another appears: it can happen that the values
> > > unsigned long do not suffice for all interval task!
> >  
> >  This is what I am trying to avoid.
> >  We should simply push the responsibility of handling all these issues
> >
> > down to
> > the runtime/target system.
> >
> >   Mario
> >  
> > > 12.04.2018 16:38, [hidden email] пишет:
> > > >   HI Aleksandr,
> > > >  
> > > >   Yes, it seems that this would fix the problem you mentioned.
> > > >  
> > > >   However, my opinion is that if we are going to mess around with this
> > > >   code, it>
> > > >
> > > > would be better if we could fix this properly. What I mean by this is
> > > > that:
> > > >
> > > > 0) Recognize that it should not be the compiler's (matiec)
> >
> > responsibility
> >
> > > > to include code that calls the tasks periodically. This functionality
> > > > should be provided instead by the runtime environment.
> > > >
> > > >
> > > > 1)
> > > >
> > > >    The compiler (matiec) should simply set up an array of struct with
> >
> > the
> >
> > > > information required to execute the tasks periodically.
> > > >
> > > > typedef task_into_t {
> > > >
> > > >    int period;
> > > >    void (*func) (void);
> > > >    ...
> > > >
> > > > }
> > > >
> > > > task_info_t task_info[3] = {
> > > >
> > > >    {3, task0},
> > > >    {10, task1}
> > > >
> > > > };
> > > >
> > > >
> > > > 2)
> > > >
> > > >   It should then be up to the runtime to do what it needs to call the
> > > >   tasks
> > > >
> > > > periodically.
> > > >
> > > >   When running on a POSIX operating system, tasks may be mapped onto
> > > >   threads.
> > > >   When running on an embedded system with no operating system, then
> > > >   the
> > > >   cyclic>
> > > >
> > > > scheduler (while(1) loop) may be used instead.
> > > >
> > > >   NOTE: This means that all runtime systems currently using
> >
> > Beremiz/matiec
> >
> > > >   will>
> > > >
> > > > need to be updated, which is why I have been putting off this change.
> > > >
> > > >   Cheers,
> > > >  
> > > >      Mario.
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 4

Beremiz-Devel mailing list
Hi, Alexandr!

Have you tried to add

if (greatest_tick_count__ )
{
    greatest_tick_count__ = ((unsigned long)-1) - (~greatest_tick_count__ + 1);
}

to int __init(int argc,char **argv) in plc_main.c?

I think this may be a temoprary workaround for __tick rollover problem...

Best regards,
Paul Beltyukov.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel