sort function

[TucsonDon]

typedef struct
{
    uint8_t hr[2];                      //[0] = start hour [1] = stop hour
    uint8_t min[2];                  //[0] = start minute [1] = stop minute
    uint8_t operation;
}TmrData_t;

void CheckTimerOrder(void)
{
    uint8_t TCount = 0;
    uint8_t j = 0;
    TmrData_t TmrData[8], Key;
    
    TCount = TmrCount();                    //count timers in eeprom
    for(uint8_t a = 0; a < TCount; a++)
    {
        GetTmrData(&TmrData[a], a);                     //get timer data from eeprom
    }
    
    /*to sort timers in chronological order by start hour*/
    for(uint8_t i = 1; i < TCount; i++)
    {
        memcpy(&Key, &TmrData[i], 5);
        j = i - 1;
        
        while((j >= 0) && (TmrData[j].hr[0] > Key.hr[0]))
        {
            memcpy(&TmrData[j + 1], &TmrData[j], 5);
             j -= 1;
        }
        j++;
        memcpy(&TmrData[j], &Key, 5);
    }
}

I am using this to sort through timers that I have stored in the EEPROM in chronological order by hour. I need to ad another sort that if the hour is the same to sort by minutes, but unsure of how to do it

 

[dougy83]

You don't need use memcpy. Just assign one struct to another to copy it. e.g. Key = TmrData[i];
To sort by hour and minute, update your comparison function, i.e. TmrData[j].hr[0] > Key.hr[0] to include the minutes, e.g. TmrData[j].hr[0] > Key.hr[0] || (TmrData[j].hr[0] == Key.hr[0] && TmrData[j].min[0] > Key.min[0])

Note: I didn't check that your logic is correct; I just provided changes assuming your code is currently functioning

 

[TucsonDon]

dougy83 I tried it w/o memcpy but it didn't seem to work in MPLab but will try it again.

To sort by hour and minute, update your comparison function, i.e. TmrData[j].hr[0] > Key.hr[0] to include the minutes, e.g. TmrData[j].hr[0] > Key.hr[0] || (TmrData[j].hr[0] == Key.hr[0] && TmrData[j].min[0] > Key.min[0])

I will give this a go, thanks for the help!

 

[dougy83]

I tried it w/o memcpy but it didn't seem to work in MPLab but will try it again.

I think it should work

I will give this a go, thanks for the help!

Good luck!

 

[TucsonDon]

You don't need use memcpy. Just assign one struct to another to copy it. e.g. Key = TmrData[i];

dougy83 Yep it worked, not sure what I was doing wrong before.

 

[rjenkinsgb]

If I were doing it, I'd consider rearraging the time storage so hour and minute were the high & low bytes of 16 bit values.
That allows a direct comparison & the 8 bit shift to access the high byte is a fast operation.

 

[TucsonDon]

rjenkinsgb Thanks for the info

 

[Pommie]

I recently did a project (on google sheets spit, spit) which involved time. I found that if I store all times as minutes in a 16 bit variable it greatly simplified a lot of code. I had conversion function both ways for input and output. I.E toMins(), toString() etc.

Mike.

 

[Nigel Goodwin]

I recently did a project (on google sheets spit, spit) which involved time. I found that if I store all times as minutes in a 16 bit variable it greatly simplified a lot of code. I had conversion function both ways for input and output. I.E toMins(), toString() etc.

Mike.

Same applies for date maths, convert all dates to Julian numbers - and only use 'real' dates for display purposes. A lot of Arduino stuff tends to use milliseconds, or even microseconds, for all time related purposes, other than display.

 

[Pommie]

On Arduino I always use UNIX dates which are in seconds since Jan 1st 1970. I always store them as uint32_t so ALL my code will malfunction in the year 10,135!!!

Not my problem.

Mike.

 

[TucsonDon]

I recently did a project (on google sheets spit, spit) which involved time. I found that if I store all times as minutes in a 16 bit variable it greatly simplified a lot of code. I had conversion function both ways for input and output. I.E toMins(), toString() etc.

Mike.

The RTCC that I am using looks for a hr-min match for the alarms. I am storing them in 24hr format for ease of sorting.

 

[Nigel Goodwin]

Not my problem.

Have you not heard of cryogenics?

 

[rjenkinsgb]

On Arduino I always use UNIX dates which are in seconds since Jan 1st 1970. I always store them as uint32_t so ALL my code will malfunction in the year 10,135!!!

Er, no, you are a few thousand years off!
"Because the Unix timestamp uses an unsigned 32-bit integer, it does have a maximum of time that can be counted before the number “rolls over” into a negative number. Based on current Unix time, the rollover time will be 03:14:07 UTC on 19 January 2038."

I use offset UNIX format on DSPICs, with the base date set decades on from the true UNIX standard to avoid a problem for a rather longer time. eg. I'm using 1st January 2020 at present, as I don't need dates in the past.

There is an option in newer Unix-type systems to use a 64 bit time value rather than 32 bit, which gives it a range near 300 trillion years..

 

[Pommie]

I knew it was 2038 but when I worked it out (in excel) it came out as 10,135. I blame the few beers I'd had earlier.

I'm not sure where you got your quote from but unsigned 32 bit integers cannot roll over to become negative. Actually, if it really is unsigned then that doubles the interval and it'll roll over sometime in ~2206 (I think).

Mike.