DIYEFI.org Forum

I've drawn up a layout of how the code is/will be soon in freemind :



I thought maybe some discussion about aspects I haven't thought of yet could take place here :-)

I'll attach the current version to this post, feel free to modify and attach your own and we'll see where we go from there :-)

Admin.

http://freeems.wiki.sourceforge.net/Fre ... -Structure

I've put up a wiki page for this too. If you have any ideas about what we should do, or whether what I've done is crap or fantastic, discuss it here. The wiki should reflect what the code does. I made a start on it, but someone else may like to put some effort into it. Writing it out would be a good way to come to terms with what it is doing.

Admin.

Someone else was designing something similar, intending to write it all in ASM here :

http://www.fascinationsoftware.com/FS/h ... ode-1.html

I thought it was an interesting read and perhaps some of it could be useful.

Fred.

I am very happy that you've finally decided to use the non-flat hierarchy , i've heard about that freemind tool before.

I would also advise not to mix the implementation specific lingo with that of abstract design blocks.
Work out the non-linear structure of abstract blocks (to the detail level up-to and not including implementation/platform/core specific details), then work out the data flow among those blocks, then the call/execution flow would kind of flow out of it. Also, you can create a dependency graph among the blocks, which would make it a breeze to prioritize the work on these blocks - and only then, off to the actual implementation

^ only sane way to collaborate effectively on this IMO

Alex

ababkin wrote:I am very happy that you've FINALLY decided to use the non-flat hierarchy ;) , i've heard about that freemind tool before.

Look at the date of the post Alex. Nearly 3 months old :-p

;-)

Fred.

crap, my bad

i was happy nontheless as IMO it is/was step in the right direction

ababkin wrote:crap, my bad

i was happy nontheless as IMO it is/was step in the right direction ;)

Trust me, we were going in the right direction the entire time :-)

Fred.

I discovered an ancient little tool this morning, CScope and it's friend KScope. KScope draws pretty diagrams :



What it says to me is :

• Where are all the interrupts : IE, interrupts make up the majority of the code
• How did I spend so much time writing so little : IE, interrupts make up the majority of the code
• The math routine needs to be broken down into smaller chunks : I knew that already, this emphasises the point though.

Overall it's not as useful as I was hoping it would be. Then I realised why, there isn't enough depth and complexity to need such a tool just yet, and there may never be if I continue to do a good job of breaking things down a good amount without piling on function call overheads excessively.

What would be nice would be if each node had two numbers in a small font : how many lines for the function, and how many calls to it from the parent node. This would tell a much bigger story.

Fred.