Page 2 of 2
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 10:26 am
by ea3ihi
I think there is no need to copy all 1024 contacts into ram, but instead have an index in ram that maps the dmr id with the contact number, so the lookup is performed in ram to obtain the contact number, and then just one contact record is read from flash.
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 10:43 am
by G4EML
I had the same idea as David and was typing this response at the same time!
The lookup table could be created once when the radio powers up and would only need to be 5 bytes per ID (3 for the ID and 2 for the index).
To speed up the searching the list could be sorted into ID order, then it could be searched with a binary search.
This would still need 5K of RAM so it may still be too much. It would also slow down the radio power up but probably not by much.
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 10:45 am
by G4EML
If there is not enough RAM to implement this then something similar could be done in a spare area of flash, either at radio startup or by the CPS. That would at least reduce the number of flash accesses when looking up an ID.
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 10:57 am
by VK3KYY
Colin and David
Yes. That would work.
We do have at least 5k of RAM available ( and even more RAM if the linker settings were working correctly )
75mS to load the cache at boot time would not be noticeable
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 7:40 pm
by ea3ihi
I am doing a small fast and dirty test, using a structure that contains a uint32 for the tg/pc id and uint16 for the contact index.
The code can be found at:
https://github.com/ea3ihi/OpenGD77/tree/idlookup
I am initialising the cache from the splash screen, probably not the best place but I though a few more ms of splash screen wont hurt.
Code: Select all
void initialiseContactsIndex() {
struct_codeplugContact_t contact;
for (int i = 1; i <= 1024; i++)
{
codeplugContactGetDataForIndex(i, &contact);
contactsIndex[i-1].tgNumber = contact.tgNumber;
contactsIndex[i-1].contactNumber = i;
}
}
int codeplugContactIndexByTGorPC(int tgorpc, int callType, struct_codeplugContact_t *contact)
{
for (int i = 1; i <= 1024; i++)
{
if (contactsIndex[i-1].tgNumber == tgorpc)
{
codeplugContactGetDataForIndex(i, contact);
if (contact->name[0] != 0xff && contact->tgNumber == tgorpc && contact->callType == callType)
{
return i;
}
}
}
return 0;
}
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sat Jan 25, 2020 8:49 pm
by VK3KYY
Thanks David
I agree. Trying to use 3 bytes for the TG/ID instead of a 4 byte int is not necessary at the moment, I think there is enough RAM to hold the extra 1k
And even if you did try to use a 3 byte array for the TG/ID it’s possible the compiler would leave an empty byte, so that the unsigned 16 bit index is on a 4 byte boundary
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sun Jan 26, 2020 9:28 am
by VK3KYY
David and Colin
FYI.
I've written a caching system, and I've posted some code to Daniels' PR that does other things to improve the DMR ID etc lookup and caching
https://github.com/rogerclarkmelbourne/ ... 7/pull/407
At the moment, I'm still testing the final part of my cache handling for the functions when the Contacts menu screen adds or removes contacts.
Re: Contact lookup is consuming large amounts of CPU time
Posted: Sun Jan 26, 2020 9:31 am
by VK3KYY
VK3KYY wrote: ↑Sun Jan 26, 2020 9:28 am
David and Colin
FYI.
I've written a caching system, and I've posted some code to Daniels' PR that does other things to improve the DMR ID etc lookup and caching
https://github.com/rogerclarkmelbourne/ ... 7/pull/407
At the moment, I'm still testing the final part of my cache handling for the functions when the Contacts menu screen adds or removes contacts.
PS.
Alex also posted some useful information, about how to assign a variable to either of the 2 memory regions in the Lower bank of RAM.
I may also move some of the lager buffers into the Lower area, eg. the buffer that holds the 3 DMR frames of decoded audio, and see if that still works
