next topic »

[Reply #45 on:]

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.

Can you name some useful abstractions?

I'm rather invested in doing something about this. It's bugged me for some time, without any particular reason. And I feel now is a time for me to try to do something. Creating some useful abstractions, or producing some documentation. Actually both would be nice.

[Reply #46 on:]

Can you name some useful abstractions?

digital and analog read and write, millis,  delay, map,  shiftOut and pulseIn for example.



there are still quite a few hardware capabilities that would be more accessable if someone wrapped some easy to use functions around them.  Two examples:

input Capture ( measuring pulse width  in background using timer1)

event scheduling ( I wrote something for my own purposes and posted it in a thread but  think its not intuitive enough for general use, see: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1217881285)

[Reply #47 on:]

adding useful abstractions

I was interested in some of the new abstractions.


Event cheduling is indeed something to look at, will investigate your code later.


I am rather pleased with the SPin struct, it masks data in one byte that typically use 4 bytes. (one int for pin, one int for last state)
This is 4 times more space efficient.


example.pde

#include "Pins.h"

SPin led, pot, sw;

void setup()
{
  set( led, 13, OUTPUT, ON );
  set( pot, 2,  INPUT );
  set( sw,  12, INPUT,  PULLUP );
}

void loop()
{
  if(digitalRead2(sw))
  {
    set(led,ON);
  }
  set(led,OFF);
}
 

Pins.h

#include "WProgram.h"

#define constant (static const)

#define PULLUP true
#define ON true
#define OFF false

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

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

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

boolean digitalRead2(SPin& pin)
{
  return (digitalRead(pin.pin)!=pin.state ? true : false);
}

unsigned int analogRead2(SPin& pin)
{
  return analogRead(pin.pin);
}

void toggle(SPin& pin)
{
  if ( pin.mode==OUTPUT )
  {
    pin.state ? set(pin,HIGH) : set(pin,LOW);
  }
}
 

[Reply #48 on:]

I agree heartily in regard to being more careful with memory usage in the library.  For example, the digitalRead routine should be returning a byte, not an int.  There are many such improvements that could be made.

I do not however, want to force programming style on anyone.

lilbuzz

[Reply #49 on:]

I would love to see some (more) documentation on best practices and optimizations.  I've only recently discovered the Arduino and I have very little programming experience (I've done plenty of bash scripting in Linux) So what I have to work from are the examples and other folks' code.

It's important to me to learn the right way over learning the easy way within a certain scope.  But if what people post as help to others is sub-optimal, then we begin to breed a culture of slop.  I am sensitive to the problem of making things more complicated.  After all, it is the simplicity of Arduino that attracted me in the first place.

I would bet that a cursory review/update of the example code and some of the more popular docs would address the majority of the concern.

[Reply #50 on:]

"best practices"

I don't mean to nitpick, but I was never fond of the term.  "best" is a marketing term and not a scientific term.  

In some cases, people can learn "best practices" by rote, and not by reason, and thus become inflexible when having to evaluate another approach for any given situation, where that situation might have different objectives than the presumptuous authors of said "best practice".

There is often not a "one size fits all" solution.


Edit: I just read the wikipedia version:
http://en.wikipedia.org/wiki/Best_practices

Seems most of what has been presented to me as "best practices" was really a bit of linguistic drift.  A good idea under certain circumstances being presented as a "best practice".

[Reply #51 on:]

As it turns out, I've learned an interesting thing since my last post: you CAN NOT directly replace int with byte just to save memory.  The data types are handled differently by various things.  For instance a Serial.print() will output the ASCII character of a a byte value, not the number you are trying to display (maybe I need to qualify the call better, but it happened).  So I went back through and changed a number of variables to int data types just to read them.  As a noob, it makes me curious about the validity of the original post.

I agree about the "best practices" point.  But I think this thread scopes the issue to things like keeping the memory footprint small and writing code that runs as fast as possible for the needs of a project.