Aquileo | Recent changes to feature-requests

Aquileo | Allow to define timer table externally

Thu, 19 Sep 2013 11:30:51 -0000

I propose to allow to define the timer table externally via a #define (timers.c):

#ifndef HAS_EXTERNAL_TIMER_TABLE
/*  ---------  The timer table --------- */
s_timer_entry timers[MAX_NB_TIMER] = {{TIMER_FREE, NULL, NULL, 0, 0, 0},};
#endif

This allows having multiple timer threads using the same code basis without modifying the original library code, following this pattern:

// <applicfg.h>:
#define HAS_EXTERNAL_TIMER_TABLE
#define timers getTimersList()
s_timer_entry* getTimersList();

// <timers_driver.c or any other appropriate>:
static g_timer_entry* timersLists[256];
s_timer_entry* getTimersList()
{
    return timersLists[getIndexForTaskId()];
}

In this example timers[n] would expand to getTimersList()[n] with a list per running timer task, a variant would be to have the timers lists per object dictionary:

// <applicfg.h>:
#define HAS_EXTERNAL_TIMER_TABLE
#define timers getTimersList(d)
s_timer_entry* getTimersList(CO_Data* d);

// <timers_driver.c or any other appropriate>:
static g_timer_entry* timersLists[256];
s_timer_entry* getTimersList(CO_Data* d)
{
    return timersLists[getIndexForOD(d)];
}

Aquileo | Unlock reserved indexes 0x1019 - 0x11FF

Mon, 11 Mar 2013 14:15:38 -0000

Hi!
I have to use indexes from 0x1019 to 0x11FF (some of them) in my application. And it would be perfect to unlock them in Object Editor to edit.

Unfortunetly, i can't edit our local protocol and have to search alternative ways. And at the same time, a don't want to stop using CANFestival stack. So, unlocking of those indexes would be perfect!
Thank you!

Aquileo | SDO server error messages

Sat, 19 Jan 2013 10:11:26 -0000

Hello,

The SDO server of CanFestival is not sending 0x0504 0001 error message if command specifier is invalid.

Aquileo | Add more checks to SDO client operations

Thu, 09 Sep 2010 14:03:04 -0000

Hello,

I have bumped into problems with CanFestival SDO client operations
when reading/writing parameters fast from/to other CANopen modules.
The problem occurs when e.g. last read operation ended to timeout and
then immediately starting to read another parameter from the same
device. If the remote device still responded to last read request, the
response of last operation might be used to newly started SDO
operation although the response was for different parameter. This
causes confusion with the read values.

However, there's rather easy solution for this; check that the index
and subindex of the SDO response frame from the SDO server match to
newly started SDO client operation. If they do not match, simply
ignore the response. This requires following changes; implement index
/ sub-index checking to each SDO response handling frame for SDO
client branches in proceedSDO and ignoring the frames in case they do
not match. I was thinking I could implement this and send a patch for
you to add it to CanFestival version control.

How do you like the idea? I think this should be implemented to avoid
situations described above.

BR. Jari Kuusisto