Go Down

Topic: Reforming datatype practices (Read 4 times) previous topic - next topic

dcb

#30
Feb 05, 2009, 04:44 am Last Edit: Feb 05, 2009, 04:46 am by dcb Reason: 1
"As long as it does not rule out the use of 'regular' c/++"

LOL, that's a pretty big preconception :)  If you want something that is easy to pick up, read, organize and is  non-redundant and is somewhat self optimizing, we might have to think about partitioning off the C at some point.  I don't have issue with libraries using it, or assembler for that matter, and that may be where the standards documents are best suited, though still a bit of herding cats.

But hello world over serial should ideally be a one line program.  As should turning on the status LED.

Coordinate some defaults for communications so you don't have to think about it unless you want to.  Have some predefined aliases for pins/functions.   Lazy initialize the pin and serial modes based on the  function request, ie set(statusLed, low) (or high or pullup or ???), combine common function combinations into more powerful single commands.  

Define some standard buttons while your at it, and make serial printing basically the same call as LCD printing.  Get some default user I/O hardware to build on.

And yes, if you can figure out how to NOT declare variables ahead of time in a space efficient manner, that is actually a good thing.  If you control how the iterations are done and there's constants in the limits then that's pretty straight forward case for auto-size selection.  Other schemes involve dynamically growing the size of variables at runtime.

Which is reminds me of another of my favorite features, dynamic collections (i.e. vectors).  I've done it in C, but it's like 10 times as much coding as in a java counterpart.  And that leads to dynamic strings which is another nice feature.

Of course I'm just shooting in the air here, I'm sure plenty of folks are groaning at the implementation details and the cost in CPU resources and how things can't be done (and I love proving those sorts wrong), but you have to kind of put the criticisms aside for now, just think of any feature in any environment that you found real useful.  %90 of it will get cut anyway but go ahead and brainstorm a bit yourselves for now.  It's fun to pretend :)

Fjornir

Quote
Maybe it's just me, but I would prefer to think about what arduino the language *could* be, rather than weigh it down with preconceptions about C.


That's where I'm gonna have to say, "Please. No."

The big win of Arduino over BasicStamp (for instance) is that once you've outgrown a BasicStamp you've got a pile of proprietary pseudo-BASIC you then need to re-write into a 'real language'.

You outgrow Arduino you've got some workable C/C++ code ready for porting to another platform with minimal effort.

westfw

Quote
We do not need to make it a war, a debate would be nice.

Not really.  A lot of this is stuff that the "serious" programmers have long ago agreed does not have a right or wrong way, and the best to hope for is consistency, at least within a single program, and hopefully from a single programmer, and maybe, if you're lucky, from an entire company.

Given the mixed reputation of C++, and my lack of experience with it, I have to say that I really like the way that C++ features are rather de-emphasized in the Arduino environment.  Making Arduino sketches MORE C++ish would not be a good thing, IMO.

As for your example, I gotta say that "LED_Reform01" is a pretty awful name for anything ("01" ???!!  Shades of ForTran's "i", "ii", "iii"...)  I guess it could be worse; by your own standard shouldn't it be "CLED_Reform01" ?  It's a class, right?

Andrew

#33
Feb 05, 2009, 10:51 am Last Edit: Feb 05, 2009, 10:52 am by Andrew Reason: 1
Quote
Not really.  A lot of this is stuff that the "serious" programmers have long ago agreed does not have a right or wrong way, and the best to hope for is consistency, at least within a single program, and hopefully from a single programmer, and maybe, if you're lucky, from an entire company.


Don't get me started on tabs vs spaces for indentation...

Andrew

AlphaBeta

#34
Feb 05, 2009, 01:12 pm Last Edit: Feb 05, 2009, 01:13 pm by AlphaBeta Reason: 1
Quote
I gotta say that "LED_Reform01" is a pretty awful name for anything

Hehe, ofcource. I just rushed to get something done, and failed to do it properly. Good observation though.

Quote
Not really.  A lot of this is stuff that the "serious" programmers have long ago agreed does not have a right or wrong way, and the best to hope for is consistency, at least within a single program, and hopefully from a single programmer, and maybe, if you're lucky, from an entire company.


I disagree that a sort of variable datatype / naming consensus is to aim for being lucky. There is a reaason why almost all variables used in the software forum is int, and it's because all examples use ints. Just change thos int to a 'proper' datatype, and we've come a long way:)

I also agree with Fjornir about the big win with arduino being c++.

I agree that arduino should and already does 'de-emphesise' the technicalities of C++, such as function prototypes, and #includes. And arduino sould definitly continue to do so.



[size=14]Anyone disagree with me wanting to change all the ints to something more space efficient[/size], and at the same time teach the newcomers that a int matrix[8][8] is twice the size as opposed to byte matrix[8][8] and that it is better practice to select the byte datatype, is suitable?

dcb

"Anyone disagree with me wanting to change all the ints to something more space efficient, and at the same time teach the newcomers that a int matrix[8][8] is twice the size as opposed to byte matrix[8][8] and that it is better practice to select the byte datatype, is suitable?"

How do you get the computer to tell them that if it is appropriate?  Or better yet do it for them?  

If you saw a program, and wanted to see if you could "resize" a variable, what are the manual steps you go through?  You look for things that would limit a value, right?  Well how do you do that automatically?  Maybe you have to analyze all updates and access to that variable, and any other variables used to update that variable, and see if they lead to constants.  Maybe you have to simulate the program on the pc and see how big the values get, though that wouldn't be as conclusive.  

But is there a way to do it and leverage that PC more and make it more transparent?  Does the problem space get any easier if you define the language, or if you assume backwards compatibility to 1972?

AlphaBeta

Quote
Or better yet do it for them?  

Are you proposing to implement a php like datatype abstraction?

I did not quite see where you wanted to go with you last post dcb :( I'm probably just too tired.


As for how to select datatypes, I usually think something in the likes of:

is variabale always positive ? unsigned : signed;
is variable a pin ? byte : continue;
is variable for use in PWM / analogWrite ? byte : continue;
is variabel to hold anaogRead ? int : continue;
is variable for use with millis ? long : continue;

And continue through all elements that has to be concidered for your program.

westfw

Quote
Anyone disagree with me wanting to change all the ints to something more space efficient

Yeah, I think so.  Overall in the forums, I think I see more people running into problems with the limited range of "small" datatypes (even "int", and a lot of people expecting "float" all the time) than I see people running into problems using up all their RAM.  Using "byte" (which is unsigned, right?  You don't want to change the "ints" to "signed char" and have to explain how that's really a number, do you?) would multiply those problems without a lot of benefit to most users.  Making code smaller and more efficient when it doesn't NEED to be is generally a thankless task, and not really very useful.
(too many of the examples need a "bit" datatype (pin or LED state, right?), which C doesn't have (C++ doesn't have it either, does it?))

mem

#38
Feb 05, 2009, 06:03 pm Last Edit: Feb 05, 2009, 06:04 pm by mem Reason: 1
C++ does have the bool datatype, its the same size as a byte.

AlphaBeta

Quote
I think I see more people running into problems with the limited range of "small" datatypes

I think this is because no one ever specifically enlightened them about the fact that there is different datatypes. With different storage capabilities.

Quote
(too many of the examples need a "bit" datatype (pin or LED state, right?), which C doesn't have (C++ doesn't have it either, does it?))


Code: [Select]

struct SPinStates
{
 byte bPinState1 : 1;
 byte bPinState2 : 1;
 byte bPinState3 : 1;
 byte bPinState4 : 1;
 byte bPinState5 : 1;
 byte bPinState6 : 1;
 byte bPinState7 : 1;
 byte bPinState8 : 1;
};

SPinStates pinStates;
pinStates.bPinState=HIGH;

digitalWrite(13,pinStates.bPinState1); //turn on led

AlphaBeta

#40
Feb 06, 2009, 08:34 am Last Edit: Feb 06, 2009, 08:42 am by AlphaBeta Reason: 1
Quote
...Have some predefined aliases for pins/functions.   Lazy initialize the pin and serial modes based on the  function request, ie set(statusLed, low) (or high or pullup or ???), combine common function combinations into more powerful single commands.


I've started to implement something similar to this, and honestly I enjoyed it.

All initiated pins use 8bit of storage, and that includes information about pin number, pinMode and status. 8-)

Look at this Blink.pde equivalent:


[size=14]Example.pde[/size]
Quote

#include "Pins.h"

pin(13);

void setup()
{
 set(pin13,OUTPUT);
}

void loop()
{
 delay(1000);
 toggle(pin13);
}



[size=14]Pins.h[/size]
Quote

/*
||
|| File:     
||   Pins.h      
|| Author:
||   Alexander Brevig  
|| Created: 
||   2009-02-06  
|| Last Update:  
||   2009-02-06      
||
|| Description:        
|| Implement functionality for pin data wrapped in one byte.
|| Information include:
||   -Pin number  
||   -Pin mode    
||   -Pin state
||
|| License:
|| GNU Lesser General Public License 2.1 or later .
||
*/

#include "WProgram.h"

#define pin(x) SPin pin##x={x}

struct SPin
{
 byte pin : 5;
 byte mode : 1;
 byte state : 1;
};

void set(SPin& pin,boolean mode,boolean state=false)
{
 pin.mode = mode;
 pin.state = state;
 pinMode( pin.pin, pin.mode);
 digitalWrite( pin.pin, pin.state);
}

void setHigh(SPin& pin)
{
 pin.state = false;
 digitalWrite( pin.pin, pin.state);
}

void setLow(SPin& pin)
{
 pin.state = true;
 digitalWrite( pin.pin, pin.state);
}

void toggle(SPin& pin)
{
 pin.state ? setHigh(pin) : setLow(pin);
}

dcb

#41
Feb 06, 2009, 12:35 pm Last Edit: Feb 06, 2009, 12:45 pm by dcb Reason: 1
I'll stop hijacking, I promise :)  I just wanted to imagine what it might look like if we had something with little to no extra "keep C happy" lines for the usual usages (I should really check up on the arduino python folks):

imaginary.pde (complete)
Quote

set (pins.LED, ON)


Don't need setup, and don't need loop if not looping.  If we are talking arduino, we know where the LED is.

imaginary2.pde (complete, spit it out the com port at the default/current arduino debug baud)
Quote

print ("Hello World")



imaginary3.pde (complete)
Quote

set(pins.analog1,PULLUP)
loop:
  print ("Temperature is " + get(pins.analog1)/ 1110)
  wait (0.5)

loop: is basically a synonym for while 1==1:

imaginary4.pde (complete)
Quote

loop:
  print ("pin 2 is " + get(2))
  wait (1)


imaginaryblink.pde (complete)
Quote

loop:
  set (pins.LED, ON)
  wait (1)
  set (pins.LED, OFF)
  wait (1)


AlphaBeta

#42
Feb 06, 2009, 01:08 pm Last Edit: Feb 06, 2009, 01:09 pm by AlphaBeta Reason: 1
Quote
I'll stop hijacking, I promise
No such thing as hijacking this thread ;)  Keep the ideas coming!

As four you examples, I , personally , think thay are too basic like, and as stated I think the fact that arduino code / scetches are c-ish makes porting much easier. [one could argue that porting is something the beginners, which arduino aims for, care about, but I know from experience that a background in arduino makes learning 'regular' c++ much easier.]

You constantly use pins.LED and such (similar to basic port.x I think?) , I actually started with that myself. But then, you would preoccupy RAM for all pins. (while thinking of it now I realize that it is actually just 19 bytes if using my struct)

The way I implemented it now is that you have to initiate a pin to a number i.e.
pin(13) ; //creates pin struct at pin number 13
[13 could be replaced with a constant, say pin(LED) and when initializing you occupy RAM.]

The main reason I implemented such a syntax is that I think it is more intuitive to write:
set(pin13,HIGH)
for instance, than
set(pins.LED,HIGH)

I liked your ideas regarding additional defines/consts named ON OFF and PULLUP


I've also played around with a macro to encourage 'good datatype practice'

#define constant (static const)

And the one could write
constant byte someVariableName = 10;
Instead of the equvalent
static const byte someVariableName = 10;


I also have to say thet I think the programmer will loose control proportional to the amount of 'keep C happy' we remove.

For instance in you imag.pde you can neither set baud rate, nor separate between the Serial or the SoftwareSerial


I for one love the scope operators { }, and I love the ;
Sometimes this is practical, easy to read despite the density.
//align
alignX(); alignY(); alignZ();


There you see... I hijacked it right back  8-)

mem

dcb, I don't think the Arduino syntax was designed to keep C happy, its rooted in Wiring and Processing.  IMO its close enough to these to make it easy to transition from one to the other, yet its syntax is valid  C/C++  so its easy to take advantage of the avr gcc stuff where needed.

I am all for making the arduino easier to program by adding useful abstractions and more documentation rather than changing the current the current syntax.

dcb

"But then, you would preoccupy RAM for all pins"
Not a given.  And not BASIC.  But I will leave it at that.


Go Up