Skip to content
This repository was archived by the owner on Sep 23, 2021. It is now read-only.

add tuneables #152

Closed
wants to merge 5 commits into from
Closed

add tuneables #152

wants to merge 5 commits into from

Conversation

DG12
Copy link
Contributor

@DG12 DG12 commented Feb 26, 2019

Use static variables, saved in UICR, initialized to DEFINEs.
This mitigates the need to modify sources and compile to just change (the frequently requested) TX_power, transmit interval, accelerometer thresholds
ToDo: add code in gatt to allow these to be modified iff the password is == 0.

Use static variables, saved in UICR, initialized to DEFINEs.
This  mitigates the need to modify sources and compile to just change (the frequently requested) TX_power,  transmit interval, accelerometer thresholds
ToDo: add code in gatt to allow these to be  modified iff the password is == 0.
@ojousima
Copy link
Member

Let's keep this on hold until the configuration is implemented.
There should also be a proof-of-concept of the configuration using some app / web-bluetooth etc.
Configuration variables should also be stored to flash, same way as the mode is.
The tags will continue to ship as non-connectable for the time being, but if the feature does not reduce readability of the main.c code I'll consider merging it to the master branch - but no promises about merging yet.

Tagging issue #145 for reference.

@DG12
Copy link
Contributor Author

DG12 commented Feb 26, 2019

Keep on hold ( I intended that).
N.B. Code changes associated with this pull request does not change any functionality
Additional code is forth coming.
Additional discussion desired.

I don't understand why these (and mode) should be in "flash" rather than in "user information configuration registers " (UICR) which is Non-volatile memory. Seems that using UICR is much simpler. Easily findable and viewable (modifiable ?) with j-link.

@ojousima
Copy link
Member

UICR would not support wear leveling and is pretty limited in regards to amount of data that can be stored. But it would definitely be possible to store the data in UICR too.

@DG12
Copy link
Contributor Author

DG12 commented Feb 28, 2019

Regarding version 2.4.2,
As I continue to work on that, do I need to reclone and the retrofit those changes in order to contine?

Remove initialization from main to uncluttered it.
Begin initialization with setting of tunable variables used in the code to the values from NVM UICR.
This commit is for code not yes complete but a work on progress.
@DG12
Copy link
Contributor Author

DG12 commented Mar 5, 2019

Really easy(?) way to setup tuneables in UICR is using nrfjprog or j-link .
With either of them installed! and a xxx cable or Nordic development kit and ruuvi development kit
sample (not current fields)

nrfjprog --memwr 0x10001084 --val 0x02040307  #  for version 2.4.3 compile #07 
nrfjprog --memwr 0x10001088 --val 0x540007DA  # fmt 5, Tx 4,  loop 2.010 sec
nrfjprog --memwr 0x1000108C --val 0x360007DA  # acc_samp 3,  acc_resolution 6, advertis 2.010Sec,
nrfjprog --memwr 0x10001090 --val 0x0A0A0A08  #   Hos=Tos=Pos=10, batMin 2.800
nrfjprog --memrd 0x10001084 --n 32

move packet formatters from library to same directory as main.
add errorPacket
remove URL code

A work in progress
@DG12 DG12 closed this Apr 2, 2019
@DG12
Copy link
Contributor Author

DG12 commented Apr 2, 2019

I closed this pull request because I am not confident in the completeness of my code at this time and the fact that there are multiple changes between the current version and my fork (like moving packet packer from library to be with main).
I would like to go forward with the storing the tunable in UICR, copying them to static variables at startup even without any build-in way to change them. This would still make tuning MUCH easier by using nrfjprog or j-link then by recompiling.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants