Hey Chris - yep, the different groups developing these projects; i'd love to design t-shirts!
Modularizing and annotating code can go a very long way to ensuring reusability across platforms. If each team keeps their sensor-specific code clearly separated from the data-logging code, reusability should be possible.
I'm happy to help with this -- some approaches are:
use comment lines to mark sensor-specific sections of code:
// -------- start conductivity probe code ---------- //
group code by purpose, and maintain a consistent API (say, wrap code in a function with named parameters) so that copying it into another file is easier, and you don't have to disentangle board-specific bits, so instead of a series of interleaved statements, you can use a standard function like
you can separate code out into different files, which adds a little complexity in one sense, but helps maintain modularity and makes copying much easier
If we can list the different code examples we're working with here, i'm happy to suggest (and contribute pull requests for!) ways of modularizing!
Great suggestions, Chris. Also:
I have often stolen uncommented code from the internet that works perfectly and I have no idea what it does.
This is more or less the idea behind a stable API -- you don't have to know how it works inside the box, as long as you can rely on it working the same way. If you were relying on a library in this way, and the author changed what it did, they'd be breaking the API, rendering your "downstream" code useless.
Some of the best comments can clearly delineate what a block of code does as it's "external interface" without having to go through explaining every line. Then anything inside that block could be changed, as long as it fulfills that external promise.
I’m still waiting on my Riffle and I’m a rank beginner so this response needs to be accepted with a grain of salt. I believe that what Chris said is right on the point. I have coded both the KnowFlow and the mini-pearl. Beyond the obvious differences for discrete vs streaming sampling and given the same environmental sensor, there is considerable overlap in the code. That’s a fair number of caveats, but coding with one goes a long way toward coding the other. David
Cool. We'll have to get a third answer or Gretchen won't know what to think.
Hi all, third answer here.
Thanks for asking the question Gretchen, I actually have the same question. So this is not exact answer, I am hoping someone could correct me on this.
The drawing is my understanding of the difference between products(brands). I don't think KnowFlow is a datalogger. I hope to change the
arduino uno part of knowflow to Riffle, since it's cheaper, smaller, easier to put into bottles, etc.
concerning the code side, majority of KnowFlow's code is about control the sensors, I think can be used for other board as well.
@rockets, what's your opinion?
Is this a question?
Click here to post it to the Questions page.
OMG, the image layout is horrible from my laptop, help needed
:-) sorry, i'll push a new change which will fix this in a bit!
Fixed! Thanks for finding this issue!
the pic is great. crystal!