Go Down

Topic: TABS (Read 992 times) previous topic - next topic

peter1929

i am new, can any one point me in the right direction.

Can you place a different sketch into a different TABs,so they will compile together?

What do you do about the 2 VOID SETUP in both sketches.

Si

Nope, the sketch all has to be in one file, unless you want to create a library.

http://www.arduino.cc/en/Hacking/LibraryTutorial
--
My New Arduino Book: http://www.arduinobook.com

peter1929

would this work ?if  i had a switch control sketch that work great, i would make a tab and call it switch.h , than add Include switch.h into main sketch, would this work?

i would like to keep the main sketch clean.

Si

What do you mean by 'Tabs'. The bit at the top of the Arduino editor looks like a tab, but I thought it was just a title. I don't think you can make multiple document tabs for one sketch.

It is just C, so, you can use #includes - see the previous post on libraries.

But -- guessing you, like me, are from a 'BIG PROGRAMMING' background and feel the need to head entropy off at the pass, just consider that a BIG Arduino sketch is 100 lines of code. Anything bigger and there is a good chance your code is unnecessarily complex - or what you are trying to do requires more than is sensible with 16MHz and 1K of RAM.

--
My New Arduino Book: http://www.arduinobook.com

Cylindric

Anything bigger [than 100 lines] and there is a good chance your code is unnecessarily complex
I hear this a lot, but I'm not convinced.  Can anyone tell me what the overhead is of having a method in it's own class in an include, compared to having the method in the main .pde?

Of course if you need sub-microsecond timing you're in the world of playing with registers manually, but for more "real time" (not real-time) situations it seems prudent to have isolatable and testable units.
Current Projects: Rodentometer - Hamster Endurance Moni

robtillaart

Quote
Can anyone tell me what the overhead is of having a method in it's own class in an include, compared to having the method in the main .pde?


This is about the OO paradigm called encapsulation. A class works more or less as a black box with a strict interface, it abstracts a piece of functionality.  The interface of a class tells you WHAT it can do for you but not HOW it does this internally. This prevents interference between internal code of classes and main program. If all code is in one sketch - or worse - all in loop() then there is a bigger chance of interference between all variables. It is not that there IS interference, is about a chance.

The abstraction of a Class is in fact no different as calling a function e.g. sin(x). That is also a (well known) abstraction of some complex math you probably don't want to write yourself. In arduinoland there are many classes e.g. for sensors that hide implementation details like how to communicate, reset, calibrate and get a meaningfull value out of the sensor. Another advantage of classes is that it is easier to reuse, both inside one program e.g. an array of sensors, or between programs.

That said, you can put (almost) all functionality of a class in in your main PDE with similar result. The only drawback is that the source file gets quite long which implies quite some scrolling as the Arduino IDE doesn't support code-folding. My biggest irritation is that scrolling takes a lot of time.


Quote
Anything bigger [than 100 lines] and there is a good chance your code is unnecessarily complex

Most of my serious applications are beyond 100 lines, largest are over 1000 lines of code - without counting the classes - but including comments.  100 is just a number, a first order of magnitude. But it is only indicative at best as you know that in C and C++ you are allowed to put all the code in one line or split it over multiple lines! So don't use Lines of code (LOC) as metric for complexity, there are far better ones:
1 count # elementary variables
2 count # compound variables (structs unions)
3 count # functions
4 count # classes used
5 count # branches (if, else, switch)
6 count # iterations.
7 count # operators (assignment, boolean etc)

finally count # lines of code LOC (there he is again)

A better indication of the programs complexity C = sum(1..7) / LOC    (apply weights to 1..7 if you like)
This number indicates the complexity per line of code.
e.g.  x = a * t^2;   is complexer than x = y

If the complexity per line is increasing the overall complexity is increasing, but complexity is doesn't automatically mean that it is unneccessary complex.

On the other hand good analysis often results in more than one solutions for the same problem that often differ in complexity. Often people stop thinking when they find the first solution for their problem and start coding, resulting in suboptimal code. If it does the job, it is OK. But if maintaining code is also part of the job (99% of the time) everybody prefers code that is less complex if possible. The first thing todo is document code well that is adding comments that explains more than "x++, here we increase the counter x". In a second step one can optimize the code reducing its complexity akak refactoring.  In a 3rd step one can redo the problem analysis to see if there are better ways to tackle the problem.

To make the circle round, OO techniques help to reduce the complexity of a program, both at design level as one can model the system on multiple abstraction levels, and on code level as it separates functionality in some logical way (OK if the design sucks ....)

my 2 cents,
Rob








Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

PaulS

Quote
My biggest irritation is that scrolling takes a lot of time.

Not with my mouse. Now, scrolling to the right place, that's a different story. Up a little, no down a little, no back up some, stop!!!!

Go Up