Jayutmb
My background is in drug development for cancer ( this robot stuff is quickly becoming my favorite hobby and i am slowly picking up on this stuff) ... So dont burn me if this is totally stupid or already done by someone
Anyhow... So I am great with logic flow ..just no so much with all the scripting jargon out there... How cool would it be if someone came up with a compiler program that let you write out your logic flowchart with all the squares,circles,if/then boxes/lines connecting flow..ect then it would do the "scripting" in the background that corresponded with the flowchart... and for things that require physical things like servos for example ... just drag and drop the items from a list that goes with items that have action, i.e "servos" ..ect...
Anyhow that is something that I think would be a huge boon for people like me who have the logic down.. just lack the exposure to scripting ...
Ok start flaming me
Nowadays visual programming tools combine both control and data flow into kind of event driven programs with implicit events. If you ever coded event driven apps, like for Windows or other GUI's, then you know how hard it is to figure out what's going on at runtime, even more inside a robot with sensors firing without close relationship to the control flow. I was really impressed when I found out how much visual programming can help in such a scenario :-)
Learning to have a good code structure layout can mean the world towards understanding your code's paths and making troubleshooting easier on yourself. In my line of work we have block diagrams that show flow or we have a set of requirements that state how the code should work. As a firmware engineer, I would much rather have a set of requirements than a flow chart to work from.
@orwnic82 Which type of "firmware" do you mean - embedded or low level code, libraries...? High level application specific languages deserve a lower level framework, i.e. kind of an OS and libraries, with different development requirements in each area.
But I don't see a big difference in flow charts, state diagrams, and other forms of requirements, as means for the description of the goals. That's independent from the implementation, where different techniques may suit better. In either case the verification of a professional implementation requires that each party can determine or demonstrate that and how the goals are reached. This suggests to me some formal layer on top of an implementation, understandable by both the ordering party and the contractor. I.e. they should speak the same "language", be strict or sloppy, textual or graphical. Even if the same person defines and implements her application, she should have such a choice.
@dodi
I am not saying anything against either method, just my preference. I'm also just saying that if he manages his code correctly then he should be able to recognize the paths it flows through and anyone else should be able to apprehend it.
I mostly program in vhdl now. I have dealt with programming ADA and assembly a couple of times but that's mainly on older systems. When it comes to mapping code in assembly that's a whole different story cause those instructions are specific register moves. So I am not really trying to bring that up as reference to the current topic.