Copying of the calibration data

Discussions related to the firmware code development
VK3KYY
Posts: 7475
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Copying of the calibration data

Post by VK3KYY » Thu Mar 05, 2020 11:08 am

I've pushed a code change to GitHub that copies the calibration data to address 0xf000 in flash, if that address does not contain the calibration data.

This will now allow us to extend the DMR ID database, to go from 0x30000 to the end of Flash !

But I still need to update the CPS to have this feature.

ea3ihi
Posts: 87
Joined: Fri Jan 10, 2020 9:28 pm
Location: Barcelona, Spain

Re: Copying of the calibration data

Post by ea3ihi » Thu Mar 05, 2020 6:15 pm

Will this have some impact if people wants to go back to the original firmware or a previous version?

VK3KYY
Posts: 7475
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Copying of the calibration data

Post by VK3KYY » Thu Mar 05, 2020 8:14 pm

ea3ihi wrote:
Thu Mar 05, 2020 6:15 pm
Will this have some impact if people wants to go back to the original firmware or a previous version?
Not initially, because the new location of the calibration is not used by the official firmware.

Only when I modify the DMR ID upload, to use the old calibration data store location, would going back become difficult

ea3ihi
Posts: 87
Joined: Fri Jan 10, 2020 9:28 pm
Location: Barcelona, Spain

Re: Copying of the calibration data

Post by ea3ihi » Thu Mar 05, 2020 8:34 pm

Only when I modify the DMR ID upload, to use the old calibration data store location, would going back become difficult
That is what i suspected.

Is it possible to make it an option in the CPS? Maybe some users do not need the extra DMR id space and prefer to keep the callibration copy intact.
How much can the dmr id data grow with this change? We will use also more space in ram for the cache

User avatar
F1RMB
Posts: 2517
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France

Re: Copying of the calibration data

Post by F1RMB » Thu Mar 05, 2020 8:45 pm

Hi,
ea3ihi wrote:
Thu Mar 05, 2020 8:34 pm
...We will use also more space in ram for the cache
Nope.

Cheers.
---
Daniel

VK3KYY
Posts: 7475
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Copying of the calibration data

Post by VK3KYY » Thu Mar 05, 2020 9:24 pm

F1RMB wrote:
Thu Mar 05, 2020 8:45 pm
Hi,
ea3ihi wrote:
Thu Mar 05, 2020 8:34 pm
...We will use also more space in ram for the cache
Nope.

Cheers.
---
Daniel
There is only 128k RAM total and most of it is now already used.

BTW.

Daniel, I noticed some code in the SPI Flash read which is ineffecient.

Before every read, there is a separate read of the status register to check if the flash is busy.

Flash should only become busy while it is being erased, so I think we can improve this and greatly improve the speed to read small items of date e.g. for DMR ID lookups etc.

I don't know who added this, but they did not consider the efficiency (PS. I don't think it was me, but perhaps my memory is not that good)

User avatar
F1RMB
Posts: 2517
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France

Re: Copying of the calibration data

Post by F1RMB » Thu Mar 05, 2020 9:34 pm

Hi Roger,
VK3KYY wrote:
Thu Mar 05, 2020 9:24 pm
F1RMB wrote:
Thu Mar 05, 2020 8:45 pm
Hi,
ea3ihi wrote:
Thu Mar 05, 2020 8:34 pm
...We will use also more space in ram for the cache
Nope.

Cheers.
---
Daniel
There is only 128k RAM total and most of it is now already used.

BTW.

Daniel, I noticed some code in the SPI Flash read which is ineffecient.

Before every read, there is a separate read of the status register to check if the flash is busy.

Flash should only become busy while it is being erased, so I think we can improve this and greatly improve the speed to read small items of date e.g. for DMR ID lookups etc.

I don't know who added this, but they did not consider the efficiency (PS. I don't think it was me, but perhaps my memory is not that good)
About the SPI status check, I don't know who added that (not me for sure, didn't touched low level SPI functions).
Okay for the speedup, sure if it stops doing checking before every read.

@ea3ihi there is no real cache for dmrid, it's just optimization about how to lookup the data.

Cheers.
---
Daniel

VK3KYY
Posts: 7475
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Copying of the calibration data

Post by VK3KYY » Thu Mar 05, 2020 10:33 pm

I had a quick look at the code and I think perhaps the SPI status check was part of the code which I originally ported into the OpenGD77, but somehow its become part of the Flash read

I looked at a lot of the code and it does not seem to check the response code, and I also did some tests and the Flash chip never returned busy, even when reading and writing from the CPS.

So I've commented the code out, and we can test it without that additional overhead.

ea3ihi
Posts: 87
Joined: Fri Jan 10, 2020 9:28 pm
Location: Barcelona, Spain

Re: Copying of the calibration data

Post by ea3ihi » Fri Mar 06, 2020 7:31 am

When we talk about the dmr ids we are talking about the contacts, right?

Code: Select all

typedef struct
{
	uint32_t tgOrPCNum;
	uint16_t index;
} codeplugContactCache_t;


typedef struct
{
	int numTGContacts;
	int numPCContacts;
	codeplugContactCache_t contactsLookupCache[1024];
} codeplugContactsCache_t;

__attribute__((section(".data.$RAM2"))) codeplugContactsCache_t codeplugContactsCache;
If we increase the number of contacts we will need more ram for the lookup cache.

User avatar
F1RMB
Posts: 2517
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France

Re: Copying of the calibration data

Post by F1RMB » Fri Mar 06, 2020 7:38 am

Hi,
ea3ihi wrote:
Fri Mar 06, 2020 7:31 am
When we talk about the dmr ids we are talking about the contacts, right?

Code: Select all

typedef struct
{
	uint32_t tgOrPCNum;
	uint16_t index;
} codeplugContactCache_t;


typedef struct
{
	int numTGContacts;
	int numPCContacts;
	codeplugContactCache_t contactsLookupCache[1024];
} codeplugContactsCache_t;

__attribute__((section(".data.$RAM2"))) codeplugContactsCache_t codeplugContactsCache;

If we increase the number of contacts we will need more ram for the lookup cache.
Nope, what you're displaying is the codeplug contacts.

Code: Select all

typedef struct dmrIdDataStruct
{
        int id;
        char text[20];
} dmrIdDataStruct_t;

#define MIN_ENTRIES_BEFORE_USING_SLICES 40 // Minimal number of available IDs before using slices stuff
#define ID_SLICES 14 // Number of slices in whole DMRIDs DB

typedef struct
{
        uint32_t entries;
        uint8_t  contactLength;
        int32_t  slices[ID_SLICES]; // [0] is min availabel ID, [REGION - 1] is max available ID
        uint32_t IDsPerSlice;

} dmrIDsCache_t;

Cheers.
---
Daniel

Post Reply