Discussion about RF12Demo state / git tagging (was RoadMap)

[TheDistractor]

All,

Been away a while - again!! I see lots small changes in RF12, Is there a RoadMap anywhere:

I just quickly scrolled through and sort of picked out the following:

JNu - I can see some #defines to help keep code succinct for this little uC, but code base is still growing. My assumption would be that many RF12Demo functions could be made optional and #defined out for JNu by default, making it an opt-in for that uC. At moment looks like some functionality is hard-opted out rather than flexibly excluded. Why am I bothered - well my TRV control project is mainly ATTiny84/JNu. No big issue because most of this seems to be in RFDemo, not driver.

Tuning - looks like we have option to tune radio - specifically by tuning all 'leaf' nodes against 'central' nodes and adjusting 'leafs' - benefit looks to be more efficient power / range ratio = better power use.

Rearrangement of config string - better to re-issue back into cli as well as accommodating tuning data.

Nodes Visibility Database - looks like we allocate data matrix to keep an eye on 'leaf' nodes we have seen - perhaps related to tuning?

I'm happy to tighten up code for JNu use, but think would be best to understand current direction and thrust of changes. Could anyone elaborate on a basic RoadMap first?

--lightbulb

[JohnOH]

Eekh, you have caught me playing. 
I'm afraid I don't have a road map, I was exploring tuning as a
technique to get around marginal crystals on some RFM12B. I'm happy
with that now and align all my nodes to a single JN USB. @jcw then
mentioned node number allocation as a precursor to wireless sketch
updating and I adjusted the tuning sketch to do that when 31i is
used.  
I don't know if you use RF12Demo in T84, I have one running a
chopped down version but I now think we should forget about running
Demo on the T84 and use Tuner3 to set up its eeprom - if required. 
I looked at @jcw's wireless loading work and because my C is quite
weak I got stuck in considering how to overwrite the active sketch
with a wireless download. So I was considering a method to return
commands from RF12Demo to a remote node as it communicates to the
centre using ACK - return a command byte with the ACK. 
I thought that storing the remote node eeprom values centrally would
give a few values that might be useful for encrypting wireless
downloads and also provide a basis for managing the remote nodes -
if some wireless download method transpires. 
To be honest I was just exploring stuff I doubt that much will make
it into the mainline as I see that @jcw's wireless download strategy
looks like a ground up build and therefore long and hard. 
John.

[TheDistractor]

JohnOH,

Nothing wrong with playing about a bit - some good progress comes from this method.

I do think that a short RoadMap would be beneficial to all (simplest is to use this Issue List as a sort of gauge of where we are going and how far we have got.)

Perhaps you could retrospectively add some issues to give us an idea. And close them off (as if your commits had fixed them).

Have you considered using 'tags' in your commits to keep your feature sets together?

ps: I do use RF12Demo on T84, although is older and slightly customized. This is one reason why I commented as I'd like to update my codebase shortly.

Willing to help once I get a feel for direction. Would be great to see some retrospective issues ;)

--lightbulb

[jcw]

I'm traveling and won't be able to do anything for another week. Roadmap is a very good idea. Tuning can be done several ways, see Martyn's notes on #57.

Agree on stripping down rf12demo for attiny with a few conditional define's. See also mharizanov's work for the openenergymonitor project, they have an attiny-based board for the rpi with a stripped rf12demo, iirc.

One goal for me would be to extend rf12 driver to support tuning, and probably also rssi measurement, if it can be done without bloat for projects not needing this. Then we can integrate John's work into the master branch.

Second goal for me is to throttle back my ambitions for the jcw/jeeboot project on github so it will actually become feasible and available... been in limbo far too long.

[jcw]

@JohnOH please omit quoted text from your replies, it makes - whoops, earle send!

it makes the comments on https://github.com/jcw/jeelib/issues/60 harder to read...

[jcw]

didn't mean to close this, stupid ipad browser, my mistake...

[JohnOH]

RF12Tune3 compiles to "Binary sketch size: 5,962 bytes (of a 8,192 byte maximum) - 72% used" on a T84. I like the idea of a slim sketch/program stored in PROGMEM that I can use to overwrite my sketch space or load itself into high RAM and then pass control to. Ideally it would then begin transmitting requests and accepting downloaded packets to flash a new sketch into the chip.

Is there capability in the linker to arrange sketches such that they can be loaded as an overlay to each other? This might allow the jeelib/rf12 code to be shared across the image as the overlay happened. Big ask!

[JohnOH]

I've been foolish and reverted a commit to git. I have more changes locally but apparently I have detached my head. If anyone can see a solution to this I would welcome your assistance.

[TheDistractor]

@JohnOH ,

Difficult to see where you are at.

Before you do anything, take a temp copy of your entire jeelib folder somewhere safe, all the magic is in the hidden .git folder inside there.

With that safe, you can then first 'stash' your changes - read up on git stash. (practice on a dummy repo).

then your git should have given you a commit id for the detatched head. something like [detatched HEAD xxxxxxxxx]

Assuming your on branch RF12demo or whatever.

git checkout rf12demo git merge xxxxxxxxxx git checkout rf12demo (and if all looks good at this point) git push

if not, you can always keep restoring your temp folder over top and try other options.

--lightbulb

[TheDistractor]

ps: you only needed stash if you wanted to pull uncommitted changes back, so you may want to clear out your stash and loose anything there once you get back to normal.

--lightbulb

[JohnOH]

Thanks lightbulb, a job for the morning I think. I was only editing RF12Demo so hopefully just one file affected.

I had a go with tags, I'm not sure if it made it into git. I use Win7 Github and it doesn't seem to know about tags. It is probably me but I needed to use the shell to do command line tag commands and it permitted posting of comments in much the same way as I do in the Win Github windowed environment.

git tab -a Version1 - m "Initials release"

John.

[TheDistractor]

@JohnOH

note: to be clear - when i refer to rf12demo above (git checkout rf12demo) that is the "branch" that your code changes are in.

Tagging is really against the repo/commit 'state' and not against specific files, but in effect allows you to pin the entire repo at a know state through the pin, you can then always download that 'tag' at any time. Or simply clone repo and checkout to that tag. We can then say download the repo at v1.0.1 (with tuning) etc or v1.0.2 (NodesList) etc. You dont need Tags at every commit. Tags are really useful for identifying feature sets (like RoadMap items ;)

So in short (imho), use tags for then you have 'finished' a feature and its all nice and checked in and tested and you are telling the world that at this 'tag' point the repo delivers this nice feature that is ready for use.

ps: your tags have made it to git:

If your using windows, then as follows: git gui (gitk) ->Repository->Visualize "branch'es" history right click the relevant commit in the top left pane choose "create tag"...

if your using tortoiseGit (my recommend as it seems more productive once you get used to it imho) Right-click on git repo, -> "create tag" select params on resulting form.

--lightbulb

[jcw]

What's the status of this? Can we take the discussion to the forum or turn it into an issue on Redmine, if it's still relevant? Not trying to sideline this, more an attempt to restart with a proper understanding...